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Fig. 27 



create table DomainClients 
(DCserverName text not null, 
DCactive int not null, 
DCfirmID text not null, 
DCfirmName text not null, 
DCfirmLogo text not null, 
DCsitelD text not null, 
unique (DCserverName), 
unique (DCfirmID, DCsitelD)); 

update tables set table_owner = 'nsadmin' where table_name 
'DomainClients'; 



Fig. 28 



create table DCCIientSources 
(DCSfirmID text not null, 
DCSsourceFirmlD text not null, 
unique (DCSfirmID, DCSsourceFirmlD)); 

update tables set table_owner = 'nsadmin' where table_name ■■ 
'DCIientSources'; 



Fig. 29 



create table DCObjects 
(DCOobject large_object not null); 

update tables set table.owner = 'nsadmin' where table_name 
'DDobjects'; 
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Fig. 30 



create table DCObjectDestinations 
(DCODtarget text not null, 
DCODIoHandle text not null, 
DCODreceived timestamp not null, 
DCODprocessed timestamp, 
unique (DCODtarget, DCODIoHandle)); 

update tables set table_ower = 'nsadmin' where table.name = 
'DCObjectDestinations'; 



Fig. 31 



create table Indexes 
(IndexlD int not null, 
IndexDescription text not null, 
IndexBaseType int not null, 
IndexParentID int not null, 
indexAbbrvtext not null, 
unique (IndexlD)); 



update tables set table_ower = "nsadmin' where table.name = 'Indexes'; 
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Fig. 31a 

create table Channels 
(ChannellD int not null, 
ChannelName text not null, 
Channel Description text not null, 
unique (ChannellD)); 



update tables set 



table,owner='nsadmin' where table_name='Channels'; 



Fig. 31b 



create table ChannelContent 

(CCchannellD int not null, 

CCcontentID int not null, 

CCtype text not null. 

CCsource text not null, 

unique (CCchannellD, CCcontentID)); 



update tables set table_owner 



='asadmin'wheretable„name='Channelcontent'; 



Fig. 31c 



create table ChannelTemplates 
(CTchannellD int not null, 
CTtemplatelD int not null, 
CTattributes text not null, 
CTsources text not null, 
unique (CTchannellD, CTtemplatelD)); 



update tables set table_owner 



='nsadmin•wheretable_name='ChannelTemplates■; 
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Fig. 32a 



create table WorkGroup 
(WGgroupID text not null, 
WGname text not null, 
WGmembership text not null, 
WGcommunity int not null, 
unique (WGgroupID)); 



update tables set table.ower = 'nsadmin' where table.name = 'Workgroup'; 



Fig.32b 



creat table WgroupContent 
(WGCgroupID text not null, 
WGCtype text not null, 



WGCsourcelD text not null, 
unique (WGCgroupID, WGCtype, WGCsourcelD)); 

update tables set table_owner= 'nsadmin' where table. 
name= WgroupContent 1 ; 
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Fig. 33 

create table WGroupBaseContent 
(WGBCgroupID text not null, 
WGBCindexlD int not null, 
unique (WGBCgroupID, WGBCindexlD)); 

update tables set table.ower = 'nsadmin' where table_name : 
'WGroupBaseContent' ; 



Fig. 34 



create table WGroupMasterLists 
(WGMLgroupID text not null, 
WGMLmasterList large_text not null, 
WGMLtmeStamp timestamp, 
unique (WGMLgroupID)); 

create index WBMLindex 
on WGroupMasterLists 
using btreee (WGMLgroupID); 

update tables set table.ower = 'nsadmin' where table.name : 
'WGroupMasterLists'; 



Fig. 35 



create table WGroupAdhocContent 
(WGACdestID text not null, 
WGACsourcelD text not null, 
unique (WGACdestID, WGACsourcelD)); 

update tables set table_ower = 'nsadmin' where table_name 
'WGroupAdhocContent'; 
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Fig. 36 



create table WGroupAuthorMembers 
(WGAMauthorlD text not null, 
WGAMgroupID text not null, 
WGAMrestrict int not null, 
unique (WGAMauthorlD, WGAMgroupID)), 

update tables set table_owner = 'nsadmin' where table_name = 
'WGroupAuthorMembers'; 



Fig. 37 



create table WGroupViewMembers 
(WGVMgroupID text not null, 
WGVMviewerlD text not null, 
WGVMadmin int not null, 
WGVMattribute int not null, 
unique (WGVMgroupID, WGVMviewerlD)); 

update tables set table_owner = "nsadmin' where table_name : 
' WG roup ViewMem bers'; 



Fig. 38 



create table AddressBook 
(ABuserlD text not null, 
ABgroupID text not null, 
ABdestination text not null 



ABattribute int not null, 
unique (ABuserlD, ABgroupID, ABdestnation)), 

update tables set table_owner = 'nsadmin' where table.name = •AddressBook'; 
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Fig. 39 



create table AuthorRights 
(AuthorlD text not null, 
AuthorlndexlD int not null, 
AuthorAttribute int not null, 
unique (AuthorlD. AuthorlndexlD)); 

update tables set table_owner = 'nsadmin' where table.name . 
'AuthorRights'; 



Fig. 40 



create table Viewers 
(Viewer! D text not null, 
FullName text not null, 
AdminFlag int not null, 
DefWorkGrpID text not null. 
Def Attribute int not null, 
Passwd text not null, 
unique (ViewerlD)); 




Fig. 41 



create table WGContentListAttributes 
(WGCLAgroupID text not null. 
WGCLAIistNumber int not null, 
WGCLAattribKey text not null, 

update tables set table.owner = 'nsadmin' where table.name = 
■WGContentUstAttributes'; 
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Fig. 42 



create table WGContentlistCriteria 
(WGCLCgroupID text not null, 
WGCLCIistNumber int not null, 
WGCLCcontentType text not null, 

WGCLCcontentSource text not null. o~,r,tentTun« 
unique (WGCLCgroupID, WGCLCIistNumber, WGCLCcontentType, 
WGCLCcontentSource)); 

update tables set table_ower = 'nsadmin' where table_name = 
'WGContentListCriteria'; 



Fig. 43 



create table CSAdminMessages 
( CSAMlevel text not null, 
CSAMclass text not null, 
CSAMheading text not null, 
CSAMinfotext not null, 
CSAMtmeStamp timestamp not null); 

create index CSAMbyOID 
on CSAdminMessages 
using btree(oid); 

update tables set table_owner='nsadmin'where 
table_name= , CSAdminMessages , ; 
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Fig. 44 



create table CSContent 

(CSCauthorlD text not null, 

CSCIinkOID oid, 

CSCheadline text not null, 

CSCfilename text, 

CSCinfo large_object not null, 

CSCtmeStamp timestamp not null, 

CSCoriginSite text not null, 

CSCoriginOlD text not null, 

CSCdataAttr int not null. 

unique (CSCoriginSite, CSCoriginOlD)); 

createindex CSCbyOID 
on CSContent 
using btree(oid); 

up date tables set table_owner='nsadmin' 
table_name='CSContent' ; 



Fig. 45 



create table CSContentBase 
(CSCBcontentOID oid not null, 

CSCBindexValue int not null, 

CSCBindexTree text not null, 

CSCBIocked int not null, 

unique (CSCBcontentOID, CSCBindexValue) ); 

create index CSCBbyContOID 

on CSContentBase 

using btree( CSCBcontentOID ); 

create index CSCBbyOID 
on CSContentBase 
using btree( oid); 

up date tables set table_owner= , nsadmin'where 
table_name='CSContentBase'; 
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Fig. 46 



create table CSContentAdhoc 
( CSCAcontentOID oid not null, 

CSCAdestination text not null, 

CSCAsource text not null, 

CSCAIocked int not null, m 

unique ( CSCAcontentOID, CSCAdestination ) ); 

create index CSCAbtOlD 
on CSContentAdhoc 
using btree(oid); 

create index CSCAbyContOID 

on CSContentAdhoc 

using btree( CSCAcontentOID ); 

update tables set table_owner='nsadmin'where 
table_name='CSContentlndexes' ; 



Fig. 47 



create table CSDistributionQueue 
( CSDQsourceTableName text not null, 
CSDQsourceTableOID oid not null, 
CSDQsourceURL text not null, 
CSDQinsertTmeStamp timestamp not null, 
CSDQretrievalf meStamp timestamp, 
CSDQtargets text not null, 
CSDQorigins text not null, 
unique (CSDQsourceTableName, 
CSDQsourceTableOID) ); 

create index CSDQbyOID 
on CSDistributionQueue 
using btree(oid); 
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F ig. 47a 

create tableCSReplicationQueue 
(CSRQsourceTableName text not null, 
CSRQsourceTableOID oid not null, 
CSRQsourceURL text not null, 
CSRQinsertTmeStamp timestamp not null, 
CSRQretrievalTmeStamp timestamp, 
CSRQtargets text not null, 
CSRQorigins text not null, 

unique (CSRQsourceTableName, CSRQsourceTableOID)), 

create index CSRQbyOID 
on CSReplicationQueue 
using btree(oid); 

update tables set table_owner=nsadmin' where 
table^name^CSReplicationQueue'; 



Fig. 47b 



create table CSReplicationQueueDestinations 
(CSRQDdestld text not null, 
CSRQDrepQOID old not null, 
CSRQDretrievalTmeStamp timestamp. 
unique (CSRQDdestID, CSRQDrepQOID)); 

create index CSRQDbyOID 

on CSReplicationQueueDestinations 

using bytree (oid); 

create index CSRQDdestldindex 
on CSReplicationQueueDestinations 
using btree (CSRQDestID); 

update tables set table.owner^nsadmin' where 
table^name^CSReplicationQueueDestinations'; 
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UNIVERSAL DOMAIN ROUTING AND 
PUBLICATION CONTROL SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

Ibis invention relates generally to the field of networking 
computer systems and more particularly to the field of 
systems for providing control over distribution, 
redistribution, access security, filtering, organizing and dis- 3 
play of information across disparate networks. 

2. Background 

In most industries and professions today there is a rapidly 
increasing need for intercompany as well as intracompany 
communications. Most companies, firms, and mstitutions 
want to allow their employees to communicate internally, 
with other employees, and externally with the firm s 
customers, vendors, information sources, and others 
throughout a work day. Depending on the nature of the 
information and the relationship between the parties, these 
communications may need to take the form of one-to-one 
communiques in some cases, one-to-many broadcasts in 
others, many to many communications, and even many-to- 
one communications. Some of these categories might also 
provide better information for all concerned if the flow of 
data is interactive and collaborative, allowing recipients to 
comment, share, and build upon what has already been 
received. 

At present it is both difficult and costly to achieve and 
manage high volumes of such communications easily, espe- 
cially if extremely sensitive, confidential or proprietary 
information must be selectively communicated not only 
internally, but externally to those companies considered 
business partners. 

In the financial industry, for example, an investment bank 
may want to communicate time-sensitive information to all 
of its investment management firm clients, and invite them 
to comment on it, while still insuring that the bank's 



transmission of information, the recipient must take notes if 
he or she wants to remember details or go over the analysis 
later in the day. When information needs to be not only 
timely, but precisely and accurately recorded for later 
reference, voice telephonic conversation becomes less 
appropriate. 

Modem facsimile machines permit the broadcasting ot 
information over telephone lines to a selected group of 
clients, as well as the transmission of charts and graphs and 
other images. This also gives the clients an accurate record 
to refer to later. However, facsimile transmission is not 
interactive, so any client comments that might have been 
offered are lost. Recipients of facsimile transmissions usu- 
ally have only a hard copy, not an electronic copy of the 
information, unless they use fax modems to receive. Thus, 
the utility to the recipient may be lowered significantly, 
particularly if such transmissions come into a common fax 
machine or mail room and take a few hours to reach the 
individual. 

Electronic mail sent over gateways between internal cor- 
porate networks is often slow, sent in plain text format (with 
any visual information usually sent as an attachment, if at 
all), and, like faxed data, is usually not indexed. As a result, 
finding the information that is wanted or needed in a stream 
. of electronic mail messages can be tedious. Recipients may 
' also be unable to use or see the attachments unless they use 
the same computer software and hardware. Many companies 
and institutions will not allow inbound or outbound attach- 
ments to email messages for security reasons. Email tech- 
o nology is essentially a store and forward process that inevi- 
tably produces many copies of the same document on the 
same network— an inefficient use of network resources. 

After encountering these problems, companies and insti- 
tutions with private, internal distributed computer and tele- 
5 communication networks took another approach to address- 
ing intercompany communications. Many gave selected 
customers and vendors information from the company s 
own internal network, by building out a separate isolated 
external network to communicate with their key business 
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investment bank may also want to receive news feeds from 
financial news services vendors on the same network that 
provides for the distribution of its proprietary information, 
as well as proprietary reports and analysis from other third 
party vendors it selects. 

A decade or two ago, the tools for handling such com- 
munications would generally have been limited to 
telephone, facsimile, overnight mail, or, more recently, 
electronic mail. Each of these media had limitations and 



network would be sent to the special external network and 
then sent on to the trading partners. This allowed larger 
documents and files to be transferred in a secure fashion to 
and from external sources. However, if an institution such as 
an investment bank wished to do this for all of its clients and 
all of its vendors, expenses and complexities increased 
dramatically. If the investment bank used one type ot 
computer systems and network software for its internal and 
external networks, and a client or vendor used another, then 
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information, much too slow. The telephone is, of course, 
much faster, but many telephone conversations are limited to 
one-to-one communications, since the telephone is a syn- 
chronous form of communication requiring the partes to 
communicate at the same time. This is not always efficient. 
For an investment bank to transmit a market analysis report 
to its clients on a one to one basis, the process is slow and 
cumbersome, and inevitably some clients would get the 
information long before others do. 

Atelephone conference call insures that several clients get 
the same information at roughly the same time and a 
conference call is interactive, so that comments from various 
clients can be expressed. However, if the number of people 
on a conference call begins to exceed some critical mass, the 
call may be more confusing than helpful. The voices of other 
clients may be mistaken for that of the investment bank s 
analyst, for example. In either type of voice telephone 
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have their network administrators configure their systems to 
work together and develop programs to provide security, as 
well as functionality. This usually involved capital outlays 
for computers, bridges(network devices that connect two 
networks using two different types of media— such as 
lObase T cable and FDDI connections), routers (special 
purpose machines that connect two or more networks and 
route messages to the correct internet protocol address), 
software and terminals, plus costs for developing software to 
handle the connections to and from the outside. To avoid 
extreme costs for equipment and special development, com- 
panies tended to restrict the number of companies granted 
this kind of access as well as the kind of information that 
could be sent or received. 

To provide affordable alternatives to direct connections, 
other companies, such as First Call Corporation offered 
networking and distribution services. For example, if an 
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investment bank wanted to deliver its research to its client, 
First Call would deliver it for a fee, and also charge the 
recipients who received it. While this eliminated the need lor 
intense capital expenditures and development costs on the 
part of both sellers and buyers of the information so 
distributed, it also effectively eliminated their control over 
the information, and its flow, too. First Call, for example, 
became a central source of information, not the bank or 
supplier, in the eyes of the clients. Since the information 
provided to First Call for distribution would be sent to all 
those who bought the service, it did not make economic 
sense for the providers to customize the information for any 
given recipient. Interactive communications were also 
impractical under this scheme. 

Then came the Internet— the worldwide system of linked 
computer networks that allows thousands of existing corpo- 
rate and institutional networks to communicate over it using 
standard communications protocols or signals. That aspect 
of the Internet known as the World Wide Web simplified 
these communications even more by providing what are 
known as hypertext links, and using HyperText Transport 
Protocol (HTTP) to allow a user to go from one hypertext 
link to another over the World Wide Web. (Hypertext is a 
way of creating and publishing text that chunks information 



brought inside a private corporate network, there can still be 
problems distributing it internally. 

Most large private networks are built of complex sets of: 
Local Area Networks (LAN) — a set of computers located 
within a fairly small physical area, usually less than 2 
miles, and linked to each other by high speed cables or 
other connections; and 
Wide Area Networks (WAN) — groups of Local Area 
Networks that are linked to each other over high speed 
long distance communications lines or satellites that 
convey data quickly over long distances, forming the 
"backbone" of the internal network. 
These private internal networks use complex hardware and 
software to transmit, route, and receive messages internally. 

Sharing and distributing information inside a corporate 
network has been made somewhat easier by using client/ 
server technology, web browsers, and hypertext technology 
used in the Internet, on an internal basis, as the first steps 
towards creating "intranets/' In typical client/server 
> technology, one computer acts as the "back end" or server to 
perform complex tasks for the users, while other, smaller 
computers or terminals are the "front-end" or "clients" that 
communicate with the user. In a client/server approach the 
client requests data from the server. A web server is a 
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hypertext links or anchors embedded in them. When a reader 
of the text clicks on a hyperlink, the hypertext software (also 
known as a browser or web browser) displays the node 
associated with that link. The collection of these nodes is a 
"web" and the Worldwide Web is a hypertext system that is 30 
global in scale. ) With the Internet and the Worldwide Web, 
widespread dissemination of some types of information 
became simplified. However, most of the information pub- 
lished on the Internet's World Wide Web is not likely to be 
sensitive or confidential in nature, since access is readily 35 
available to many. 

Internal corporate networks may have highly confidential 
business files on the same computers that form the internal 
network, as well as extremely confidential technical and 
product files that may be vulnerable to attack and theft or A0 
misuse if a connection is made between the internal network 
and the Internet. C onsequently, most companies construct 
"fire walls" between their internal n etworks and any gaje.- 
vTSvs to the external world. (See FIG. Z, where companies 
CI through C9 are shown having firewalls Fl through F9, 45 
respectively. ) A firewall is a security technique in which a 
user puts a specially programmed computer system between 
its internal network and the Internet. This special "firewall' 
computer prevents unauthorized people from gaining access 
to the internal network. However, it also prevents the 
company's internal computer users from gaining direct 
access to the Internet, since the access to the Internet 
provided by the firewall computer is usually indirect and 
performed by software programs known as proxy servers. 

Thus if a user wants to get a file from a vendor, he or she 
would send an FTP (file transfer protocol) request to the 
firewall computer's proxy server. The proxy server would 
create a second FTP request, under its name and use that one 
to actually ask for a file outside the network. This allows the 
internal names and addresses to stay inside the company. 
Use of firewalls and proxy servers can slow performance 
somewhat, and also tends to limit the types of information 
that can be sent or received to that which is less likely to be 
sensitive or proprietary. 

The use of firewalls makes it less risky for internal 
network users to bring information in from the Internet and 
distribute it internally. However, once information is 



mation. In large private networks, a server computer might 
have web server software operating on it to handle hypertext 
communications within the company's internal network. At 
the web server site, one or more people would create 
documents in hypertext format and make them available at 
the server. In many companies, employees would have 
personal computers at their desks connected to the internal 
network. In an "intranet" these employees would use a web 
browser on their personal computers to see what hypertext 
documents are available at the web server. While this has 
been an advance for internal communications over a private 
network, it requires personnel familiar with HypeTText 
Markup Language (HTML) the language that is used to 
create hypertext links in documents to create and maintain 
the "internal" web pages. If a more interactive approach is 
desired, an Information Technology (IT) specialist in some 
form of scripting, such as CGI, PERL, is needed who can 
create forms documents and procedures to allow users to ask 
for information from the server. 

Applications that need to share information internally can 
also use what is known as workgroup software such as 
IBM's Lotus Notes™ software on the internal network. 
However, this, too, requires special programming and script- % 
ing for the unique needs of the organization. J^V7?ti^ 

It is now increasingly common for intranets to connect to ^n^-*-*-* 
the Internet forming what is sometimes called an "extranet."-^ l^^^- 
The Internet, however, is essentially a passive transmission - 
system There is no automatic notification sent to clients or 
customers that a new report is available on a given Internet 
55 Web page that is external to the client's intranet. Customers 
or clients normally would have to search the Internet peri- 
odically to see if a Web page has changed, and if the change 
is something he or she is interested in seeing. Some Web 
page sites that provide fee services use e-mail to notify 
60 prospective users that the new data is available. As 
mentioned, e-mail is slow, so if the data is also time- 
sensitive, the notification may not reach the customer until 
later in the day, when it may be of much less value. 

One attempt to make the Internet more interactive has 
65 been offered by Intermind, namely a form of hypertext, 
called hypercommunicatioDs. In this approach, a number ol 
directories are built at various sites, in a fashion analogized 
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to "speed dial buttons" on ordinary telephones. When a user 
wishes to get information from a site connected by 
hypercommunications, he or she "pushes" the "speed dial" 
button for that site, and is automatically linked to it, through 
directories created by the Intermind software. This approach 
also allows a publisher of information to poll subscribers to 
see if they are able to receive. If they are, and the publisher 
has new data to give them, the publisher "dials" his or her 
"speed button," thus sending the data. This helps solve the 
problem of notifying the customer that new information is 
available. 

However, making information produced internally avail- 
able selectively to external business partners via the Internet 
is an inefficient process if done manually by each author of 
internal information, even with such directories. Commin- 
gling internal information with external sources of informa- 
tion on the same intranet is also labor intensive and ineffi- 
cient if done manually, even with the "speed button" 
approach. This approach does not provide publication con- 
trol over the data, nor indexing nor organized presentation of 20 
the data. Nor does it solve the security problem posed by 
allowing others to access a website without a "firewall" or 
similar kind of access protection. 

Another option that became available to an information 
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administration and maintenance. A setup such as this, in 
which the customers use Web browsers to gather informa- 
tion from a supplier's network, is called a "pull" model, 
because the customers still have to actively seek out the 
information. To simplify the administrative tasks as much as 
possible, it makes sense for the information publisher to 
generalize the information that goes out, so that it is sent in 
a one-to-many, or broadcast format. In this type of approach, 
one publisher may organize its information in one style, 
while another may structure its data quite differently. Thus, 
it becomes extremely difficult for the clients or customers to 
index or cogently organize the data from 20 different pub- 
lishers. . ti , „ 
For the information provider to be more active, a push 
model of communication is desirable. That is, rather than 
wait for the customers to seek out information available on 
its network, the provider would like to be able to notify the 
user that the data is there and send it out automatically. 
Workgroup software, such as Lotus Notes, was usually 
thought to be the better solution for this type of intercom- 
pany transmission. Unfortunately, this usually requires a 
significant amount of software development as well as 
administrative overhead. In the example of the customer 
who is getting reports and data from 20 different investment 
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was a form of connection over the Internet that provides 
secure access, but usually to a more limited set of 
information, through a "demilitarized zone" or DMZ> using 
encryption and secure sockets. Since each company would 
want to protect the privacy of the internal data on its 30 
network, each would have a firewall around its network with 
a "demilitarized zone" (DMZ) outside or as part of the 
firewall for each other company it wished to reach. As 
shown in FIG. 2b> for example, Company A's DMZ Dl 
might be located outside its firewall Fl between the firewall 35 
Fl and Company A's gateway GI to the Internet. Within 
DMZ Dl, an area IC is shown as set aside for communica- 
tions to and from Company C. As can be seen in FIG. 2fc, the 
DMZ's of each company that wishes to communicate 
directly and securely with others must be configured to 40 
identify the intended communicants. 

If a customer needs to get information from 20 different 
external publishing sources, it may need to make 20 different 
connections between its firewall and that of the publishers 
and obtain 20 different user identifiers and passwords. A 45 
simplified illustration of this is provided in FIG. 2. For 
purposes of illustration, if companies C1-C3 are competing 
investment banks, and companies C5 through C9 are their 
customers, with C4 being a news source, a greatly oversim- 
plified network configuration is shown that uses such a DMZ 50 
configuration. Notice that bank CI has DMZ's D4-D9 for 
the news source C4 and the five customers C5-C9. Cus- 
tomer C5 has DMZ's D1-D3 for each of the investment 
banks it gets data from, as well as for news source C4. As 
FIG 2 shows, this approach results in a maze of connections 55 
P, and DMZ's, D. A simplified view of DMZ's is shown in 
FIG. 2fc, where company CI has, in its DMZ Dl, an 
application that communications with company C3. Com- 
pany C2, has, in its DMZ D2, applications CI and C3 to 
communicate with company CI and company C3, respec- 6( 

tively. . 

The DMZ approach requires each customer to obtain 
different user identifiers and passwords to gain access to 
each other company's network. For each individual at each 
customer site, someone in the investment bank's informa- 
tion technology department must assign user identifiers and 
passwords to each. This further requires elaborate network 



employee's desktop at the customer site usually arrives in a 
variety of incompatible formats. If the customer wants to get 
morning analyses from each bank, an information specialist 
at the customer site will probably have to find out what 
format is used by each sending bank, have the customer's 
programmers understand the network address schemes, as 
well as the protocols, packets, ports and sockets to be used 
for each bank, and then create or modify one or more Lotus 
Notes workgroup application programs at the customer's 
employee's desktop to convert the data into an internal 
format and bring it in. 

One attempt to address at least part of these problems is 
a technique known as "subject-based addressing technol- 
ogy" as described in U.S. Pat. No. 5,557,798 assigned to 
Tibco. Using this approach, and the example of the direct 
network to network connection via a DMZ, shown in FIG. 
la a publisher CI might set up a server at its site to publish 
information by subject. The customer C5, usually has a 
"client" application, in its DMZ D5. The client application 
denotes the set of messages to receive using human-readable 
subject names. Subject-based addressing can eliminate the 
need for the customer programmers to understand all the 
network address, protocol, packet, port and socket details, 
and even simplifies some of the modification that needs to be 
done to the workgroup software. However, it does not 
eliminate the need to configure conversion or translation 
layer software at the site to take a network feed, and to 
understand how the data that is transmitted is formatted, and 
the need to modify the workgroup software, such as Lotus 
Notes applications, accordingly. In fact, both subject-based 
addressing and workgroup software such as Lotus Notes 
usually require a significant amount of additional program- 
ming development work to be done by the users in order to 
work effectively. 

From the information publisher's perspective, a push 
model that relies on the private network-to-network connec- 
tion through firewalls, DMZ's and workgroup programs, and 
uses subject-based addressing still fails to address the dis- 
tribution control problem that may be vital to the publisher. 
If the investment bank CI of FIG. 2a provides a morning 
analysis as a subject, once the data crosses out of the bank's 
network and is disseminated over the Internet, the invest- 
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ment bank has usually lost all control of replication of the become a labor intensive chore or a w 

Analysis In most cases of subject-based addressing, the company that needs or wants to send a high volume of 

^Srwmnotevenknowwhichcompaniesareconsum- information outside selectively. ^^^^ 

" . . f t technology provides various encryption options (thus creai- 

^ITonelet of programs is written to address publi- 5 ing problems for standardization amongst companies) but 

caton contof a^d disLmtoation at one customer site, such leaves such matters as identification up to the «f°rm*Uon 

as c^Wmer C8 (in FIG. 2a) for example, using either technology (IT) department at each company to manage. 

soft~ch^ Lotus Notesor subject-baLd addressing, it The IT specialists must ass^n user 

L not always simple or easy to adapt that set of programs to to every external mdividual authored £ J^^"?*™ 

work with customer C9's network, or amongst several 10 (authentication) in the company s DMZ. Presently Uus s 

aXem customer's networks. Once it becomes desirable or usually done by manual letters of reference and manual data 

As aTadTmentioned, it is difficult to index or organize proper formats, all of this tends to place 

information received from many different sources so that it and content management in the hands of IT department 

^nTvZp^ZlsLe way on every receiver's desktop. specialists, rather than in the hands of authors and viewers 

iystems^uch as products from of information. IT specialists witbin companies are being 

iXid™Pointcast) gather data from public sources and 20 overwhelmed by requests to add new users and individuals 

^^^^Miab^Uilo^io^ administer the types of data *at can t* transited and 

individual person's request, but these systems do not usually create maintain changes and updates to the scripts, 

control replication nor do they allow any interaction with programs, networks and systems as a whole 

T^ VromZlT^y one-to-many, one way distri- It is an object of this invention to provide a universa^ 

bution Models ha, do not aUow any interaction. 25 domain routing and publication control system toat enables 

In colorations and large institutions with intranets, the selective transmission of valuable information in a 

where brokers are used, individual receivers of information manner that allows for control of rephcation and publication 

™n oroflmVe what thev see by keeping bookmarks. of the information. 

How"* toSta^ ate usu^y so customized that no two It is another object of the invention to provide a system 

" ts of t^;ml™yTo be identical. As with the external 30 that can disseminate ^formation selectively between dis- 

nronUnc systems intranets using browsers and bookmarks parate types of users and networks. 

Z alS usuX on\y able to send information in one Still another object of the present invention ,s providing 

d£ectiol A ule y r at company C8 of FIG. 2 who gets the a system that allows users to comment on and mteract with 

*n*1v<ii<; nrovided bv bank CI, usually cannot use a browser the information received. 

tocomment special form sheet has been 35 It is another object of the present invention to .minimize or 

c^eatTby S CGI scripting of some other programming eliminate the need for software development by users and 

l^S^X^-^™* invention is reducing t £ 

52 Usually make/it fifficult to standard^ across ^ — «£ - ^ 

C °MostTntranet systems connected to the Internet today do Still another object of the present invention ^ providing 

not aUow a too^idual user to request information by both a system that aUows users to access tnformaUon at the 

^urce and subject, and most do art allow an individual user speeds of their internal networks the majority of the to. 

racTaTbotn author and a viewer of information. Another object of the present mvention is providing 

Zm0 2a iUusVates, connecting consumers of informa- 45 dynamic distributed network resource 

ttonover the Internet to external information sources via lates the standardization and organization of information by 

DMZ's and secure sockets is complex and cumbersome, as subject, source or a combination or both, 

well as costly to set up and administer for the publishers of SUMMARY OF THE INVENTION 

information From the viewpoint of the consumers of infor- , 

maZ over metoernet ^should be noted that transmis- 50 These and other objects are ach.eved by system fo 

So* ove sucl a distribution model occur at "Internet managing information communications between differen 

sneed " TTiat ITo say once a request for information leaves client entities on different networks using a first computer 

cu2merC8 for example, if it goes over the Internet it is in with a disk for storing a dynamic client registry and for 

TC^^rt^Jctote, and possibly encrypted via storing resource locators containing J^?^*^ 

secure s£™. technology. In any case, its speed is the 55 server program which, when executed by the first computer, 

™e sted T( the Internet transmission links, once it causes the first computer to respond to the resource locators 

S cXmer C8's backbone network. This is usually by calling the function name uidicated into t^ first com- 

much. stower than the speed of transmission within the puter; a database management program for organizing the 

c^"'Town Eternal network. Thus, performance speed dynamic client registry; a domain commun.caUons server 

™in er ° mpa^y Communications can be problematic as .0 program which, when loaded by the web server ^program tn 

wet when™ « ftom the consumer's viewpoint. response to the appropnate resource locator is executed by 

WMk thet» of DMZ's or devices such as proxy servers the first computer and responds to resource locators directed 

help ametiowte Security problems, DMZ's also tend to to it and also directs the database management program m 

creL intent ballogs that form bottlenecks for all inter- organizing the dynamic client registry; a second computer tn 

S„ SL. For example, if the only persons 65 communications relationship with the first computer with a 

auEdTtrnsfer data outside the company's firewall to disk for storing a dynamic group registry and for storing 

Z DMZ ar tn ^formation technology specialists, this can resource locators containing function names; the second 
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computer also including a web server program which causes 
the second computer to respond to resource locators by 
calling the function name indicated into the second 
computer, the second computer also having a database 
management program for organizing the dynamic group 
registry a client side communications server program 
executing in the second computer for responding to resource 
locators directed to it, and for directing the database man- 
agement program in organizing the dynamic group registry; 
a domain communications resource locator list stored m the 
first and second computers that causes predetermined func- 
tions to be selected for execution in the domain communi- 
cations server in the first computer; and a client side com- 
munications resource locator list stored in the first and 
second computers that causes predetermined functions to be 
selected for execution in the client side communications 
server in the second computer so that communications 
between the first computer and the second computer cause 
the selected functions to be executed dynamically in order to 
manage information communications between the first and 
second computers. Client side communications servers use 
register resource locators to register their presence with the 
domain communications server. The domain communica- 
tions server notifies a client when information for it is 
available The Client side communications server receives 
the notification and copies the information from the domain 
server to its local systems, where it is distributed automati- 
cally to the users in the various groups who have permission 
to receive it Users who have redistribution authorization 
may comment on the information received and send it to the 
users and clients authorized to receive comments, whether 
internal or external to the user's institution. 

It is an aspect of this invention that it allows a company 
to communicate securely with other firms outside its private 
network without requiring the use of DMZ's at any site. 

It is an aspect of this invention that it provides a dynami- 
cally configurable domain routing and publication control 
system. 

Another aspect of the present invention is that it enables 4Q 
users to define and implement their own policies for distri- 
bution and redistribution of information on a network. 

Still another aspect of the present invention is that it does 
not require additional software development by users. 

Yet another aspect of the present invention is that it does 45 
not require additional skilled information technology per- 
sonnel to administer the system, but instead, allows users to 
administer it themselves. 

Another aspect of the present invention is that it makes it 
possible for users in a private network to receive information 
from outside the network at the speed of the private network 
most of the time. 

Yet another aspect of the present invention is that it gives 
information publishers a simple way to produce selective s; 
distributions to various clients. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 shows a schematic diagram of the present inven- 
tion showing a domain communications server and several 6 , 
client side communications servers. 

FIG la is an alternative schematic diagram of the present 
invention showing virtual connections between a domain 
communications server and several client side communica- 
tions servers. 6 

FIG 2a is a schematic diagram of private networks 
communicating externally over the Internet using prior art. 



FIG 2b is a schematic diagram of private networks 
communication externally over the Internet using prior art. 

FIG. 3 is a schematic diagram of the present invention 
showing several domains in communication with each other. 

FIG 4 is a schematic diagram of a client side communi- 
cations server according to the method and apparatus of the 
present invention, 

FIG. 5 is a schematic diagram showing illustrative inter- 
connections between a domain communications server and 
several client side communications servers according to the 
method and apparatus of the present invention. 

FIG. 6a is a block diagram of an illustrative dynamic 
client registry at a domain communications server according 
to the method and apparatus of the present invention. 

FIG. 6b is a detailed block diagram illustrative of the 
fields of a dynamic client registry at a domain communica- 
tions server of the present invention. 

FIG. 7a is a block diagram of an illustrative dynamic 
group registry at a client side communications server 
according to the method and apparatus of the present inven- 
tion. 

FIG lb is a detailed block diagram illustrative of the 
fields of a dynamic group registry at a client side commu- 
nications server of the present invention. 

FIG 8a is a list of principal domain communications 
server uniform resource locators (URL's) used in a preferred 
embodiment of the present invention. 

FIG. 8fc is a list of principal client side communications 
server URL's used in a preferred embodiment of the present 
invention. 

FIG 9 is a detailed layout of an illustrative domain clients 
list according to the method and apparatus of the present 
invention. 

FIG. 10 is a detailed layout of an illustrative client sources 
list of the present invention. 

FIG. 11 is a detailed layout of an illustrative client objects 
list of the present invention. 

FIG. 12 is a detailed layout of an illustrative object 
destinations list of the present invention. 

FIG 13 is a detailed layout of illustrative indexes accord- 
ing to the method and apparatus of the present invention. 

FIG 14 is a flow diagram of startup procedures in a client 
side communications server according to the method and 
apparatus of the present invention. 

FIG. 15 is a flow diagram of initialization of shared 
objects by a client side communications server according to 
the method and apparatus of the present invention. 

FIG 16 is a more detailed flow diagram of initialization 
of shared objects by the client side communications server 
according to the method and apparatus of the present inven- 

tion. . • ■ * i 

FIG 17 is a flow diagram showing shared object initial- 
ization by the admin server of the client side communica- 
tions server according to the method and apparatus ot the 
present invention. 

FIG 18 is a flow diagram showing shared object initial- 
ization by the tool server of the client side communications 
server according to the method and apparatus of the present 
invention, 

FIG. 19 is a flow diagram showing shared object initial- 
; ization by the agent server of the client side communications 
server according to the method and apparatus of the present 
invention. 
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FIG. 20a is a flow diagram showing the initialization of 
the dynamic client registry by the domain communications 
server according to the method and apparatus of the present 
invention. 

FIG. 20b is a flow diagram showing the creation of a 
group by the client side communications server according to 
the method and apparatus of the present invention. 

FIG. 21 is a flow diagram showing the initialization of a 
client side communication server according to the method 
and apparatus of the present invention. 

FIG. 22 is a block diagram of an illustrative user screen 
display at a desktop terminal for adding a user according to 
the method and apparatus of the present invention. 

FIG. 23 is a block diagram of an illustrative user screen 
display for entering a new user's account information 
according to the method and apparatus of the present inven- 
tion. 

FIG. 24 is a block diagram of an illustrative user screen 
display for authorizing content creation for a new user 
according to the method and apparatus of the present inven- 
tion. 

FIG. 25a is a block diagram of an illustrative user screen 
display for selecting content types according to the method 
and apparatus of the present invention. 

FIG. 25b is a block diagram of an illustrative user screen 
display for selecting content type according to the method 
and apparatus of the present invention. 

FIG. 25c is a block diagram of an illustrative user screen 
display for selecting distribution options for a user according 
to the method and apparatus of the present invention. 

FIG. 26a is a block diagram of an illustrative user screen 
display for authorizing redistribution rights generally 
according to the method and apparatus of the present inven- 
tion. 

FIG. 26b is a block diagram of an illustrative user screen 
display for authorizing redistribution rights more specifi- 
cally according to the method and apparatus of the present 
invention. 

FIG. 26c is a block diagram of an illustrative user screen 
display for assigning group access according to the method 
and apparatus of the present invention. 

FIG. 26d is a block diagram of an illustrative user screen 
display for assigning internal group access for a user accord- 
ing to the method and apparatus of the present invention. 

FIG. 26e is a block diagram of an illustrative user screen 
display for assigning external group access for a user 
according to the method and apparatus of the present inven- 
tion. 

FIG. 27 is pseudo-code in SQL format illustrating the 
creation of a domain clients table. 

FIG. 28 is pseudo-code in SQL format illustrating the 
creation of a client sources table. 

FIG. 29 is pseudo-code in SQL format illustrating the 
creation of a client objects table. 

FIG. 30 is pseudo-code in SQL format illustrating the 
creation of an object destinations table. 

FIG. 31 is pseudo-code in SQL format illustrating the 
creation of an index table. 

FIG. 31a is pseudo-code in SQL format illustrating the 
creation of a channels table. 

FIG. 31b is pseudo-code in SQL format illustrating the 
creation of a channel content table. 

FIG. 31c is pseudo-code in SQL format illustrating the 
creation of a channel templates table. 
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FIG. 32a is pseudo-code in SQL format illustrating the 
creation of a workgroup table 70. 

FIG. 32b is pseudo-code in SQL format illustrating the 
creation of a workgroup content table. 
5 FIG. 33 is pseudo-code in SQL format illustrating the 
creation of a workgroup base content table. 

FIG. 34 is pseudo-code in SQL format illustrating the 
creation of a workgroup master list table. 
10 FIG. 35 is pseudo-code in SQL format illustrating the 
creation of a workgroup ad hoc content table. 

FIG. 36 is pseudo-code in SQL format illustrating the 
creation of a workgroup author members table. 

FIG. 37 is pseudo-code in SQL format illustrating the 
15 creation of a workgroup view members table. 

FIG. 38 is pseudo-code in SQL format illustrating the 
creation of and address book table. 

FIG. 39 is pseudo-code in SQL format illustrating the 
creation of an author rights table. 

FIG. 40 is pseudo-code in SQL format illustrating the 
creation of a viewers table. 

FIG. 41 is pseudo-code in SQL format illustrating the 
creation of a workgroup content list attributes table. 
25 FIG. 42 is pseudo-code in SQL format illustrating the 
creation of a workgroup content list criteria table. 

FIG. 43 is pseudo-code in SQL format illustrating the 
creation of a client server administrative messages table. 
3Q FIG. 44 is pseudo-code in SQL format illustrating the 
creation of a client server content table. 

FIG. 45 is pseudo-code in SQL format illustrating the 
creation of a client server content base table. 

FIG. 46 is pseudo-code in SQL format illustrating the 
35 creation of a client server ad hoc content table. 

FIG. 47 is pseudo-code in SQL format illustrating the 
creation of a client server distribution queue table. 

FIG. 41a is pseudo-code in SQL format illustrating the 
creation of a client server replication queue table. 

FIG. 41b is pseudo-code in SQL format illustrating the 
creation of a client server replication destinations queue 
table. 

DETAILED DESCRIPTION OF THE 
45 INVENTION 

FIG. 1 shows a preferred embodiment of the present 
invention in a schematic block diagram. A domain commu- 
nications server Al, is in communication with a number of 

50 client side communications servers CI through C9. Each of 
these client side communications servers is located behind 
the firewall F, of its respective corporate site in a preferred 
embodiment. That is, assume Company C-One has a client 
side communications server CI, Company C-Two has a 

55 client side communications server C2, and so on, through 
Company C-Nine. Temporary logical connections or "pipes" 
P are made between each client side communications server 
in this domain and the domain communications server Al. 
In a preferred embodiment, pipes P are connections formed 

60 over the Internet using conventional TCP-IP networking 
protocol and Netscape Corporation's secure sockets with 
encryption technology. However, as will be apparent to 
those skilled in the art, other networks and protocols and 
encryption techniques could be used as well. 

65 Still in FIG. 1, it can be seen that each client side 
communications server C has only one actual communica- 
tions pipe P with domain communications server Al. Yet, 
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S^uKta L community of companies COne HKLan in Hong Kong, C2-NYLan in New York, and 

Ch ™Nke together over a network by means of C2-LNLan in London, with terminals T using standard 

S communications server Al. commercially available Web browsers also connected at 

r- The intelligent extranet that is created by the present eacn Local Area Network. 

invention allows each member client C to communicate with 10 ^ in FIG lfl> eacn s i te 0 f client C2 has a client 
those companies or institutions external to it (which have ^ TOmmunicatioIls serve r (C2-HK, C2-NY, C2-LN) con- 
authorized communicating with C) as though the other nected to ^ U)cal Are& Ne twork, and thus to client C2 s 
company were a part of the client' s own internal network or wide Network) C2WAN, forming for client C2 a smart 
intranet. In this sense, the invention creates a virtual com- intranet> according to the method and apparatus of the 
munity of corporate intranets. 1S p tesem invention. 

• To use a more specific example where the community ot simflarly cUent C 4 has multiple sites connected by a 

companies is in the financial industry, if CI, a and Ui are Area Network behind a firewall to form its smart 

client side communications servers for three different invest- mtranet whUe client C3 has only one site, its Boston 

ment banks, and C5 through C9 are client side communi- q • ^ communication with domain communications 

cations servers for investment management firms, while LA M ^ ^ ^ 

is the client side communications server for a news broad- or virtual flow 

cast organization, the investment bank at c|«t«decoB- J^.^J^Zntetions at cll ^ C2 are shown by 

munication server CI is able, by communicating , direcUy ol . „ p2 each LAN inside client 

only with domain server Al, to send information to any of Ube dotted 1m pip » r b 

Mothers in communication wUh domam co— M Sn mS'Cgl ^are, not necessarily a physical 

server Al. That is, if it wishes, the bank C-One at client side uon m ^ hard ^ e . As wfll be apparent to those skilled 

communications server CI can send its morning analysis ° ne ^ nar ° m ^ hich the ^ a,,, 

reports only to client ^"Tr^ne^whfle Z Se^ orfe wlu^m I cfieTcan^e physically connected to 

ferTco^ -preferred embodiment of the present identic, as 

aT^, Preferred embodiment of the present invention sho wn in FIG. la these logical internal connecting pipes P2 

£o wo'ks ST XfcSS tformationmanager for the also exist outside client C2, and extend to domain commu- 
SicTpatog companies or entities in this community. The 35 nications server Al, and through it, to clients CI ^and C3 UnU 

0 S invLuon thus allows the customers of investment not to client C4. That is to say in a preferred embody 

bl^C One to receive valuable information in a timely way of the present invention, a client such as client C2 can 

"J "T^oX DS to ^ meL^anTlpp'ani of the M In a preferred embodiment, all physical transmissions 
intranet, according to the metnoo ana app* he ,ween client C2 and domain communications server Al 

presentation -J^^ ^SSTSS^^S^ 45 ^pla« ov "elnternet using Netscape Corporation's 

Cl!^ e wMcn°aUo e ^£t££#^d ^ Secure Socket Layer (SSL) technologies and encryption. 

A7wul be apparent to those skilled in the art, a terminal Still in FIG. la, it can be seen that each chent C > i* 

T c^uld be any type of device capable of connecting to a own "pipe" P, ranging from PI through P6 as mdicated m 

network such as a computer, a mini-computer, a 50 the legend 00. For example, the three sites at _ chent C2 

workstation a personal computer, a CRT terminal with communicate with each other mternaUy over _ pipe 1 P2. In 

teZS ™ imernet^quipped television terminal, a key- a preferred embodiment of the P^* nwenuon *gg 

board or ouch screen and dbplay device, a personal digital a 1so seems to communicate overpipe P2 with clients CI, C3 

Smt or anyTvice thai allows a user to communicate and CS whUe, in fact, client C2 has only one actual P rpc 

w^a neCorand see information displayed. In a preferred 5S connecting i, to domain ^^ff "™ ^pte 

rmbodiment a personal computer capable of being con- be apparent to those skilled in the art, this single jipe 

nected S I network is used, together with standard Web between client C2's network and domain communications 
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in "virtual" co—caUon with the other clients or firm. 

The virtual pipes are created and managed dynamicaUy by ^ ^ ^ ^ 

the logic of the present m venUon>s domam commumcaUons availab Te database management 

server working with the client side communications servers ^ bc ^ to storc and maintain data in client 

at each site. Hence the term, intelligent extranet. 5 ^ dynamic group registry 07 stored on disk 08. Similarly, 

Still in FIG. la, note that domain communications server ^ of a num b er of electronic storage media could be used 

Al acts as the primary domain communications server for mstea d of disks. For example, in computers having sufficient 

the clients shown, but is also connected to regional or ran dom access memory, internal memory could be used as 

alternate domain communications servers A2 and A3. me electronic storage media. 

Consequently, if the computer systems or the physical i° Still in FIG. 4, a client side communications server CSS, 
communication links to the primary domain communica- here QSS ^ is shown exeC uting on computer 20 at client 
tions server Al should fail for any reason, in a preferred Boston s i tc . \ n a preferred embodiment, a client side 
embodiment of the present invention, communications can comnmn ications server CSS is used at each customer or 
continue through use of an alternate domain communica- client's site to serve all content produced internally, by the 
tions server A2 or A3. In a preferred embodiment of the « md ^ to hand i e reception of all content distributed 
present invention, domain servers keep each other up to date &om olltside me client but within the domain served by 
by automatic replication of all relevant tables and data, thus domain communications server Al. A client side communi- 
acting as mirrors to each other. cations server for a given customer may be made up of more 
As will be apparent to those skilled in the art, different than on e server executing on other computers 20 but, in a 
domains could also be linked to each other by having a hyper preferred embodiment, each server for that given client uses 
or super domain communications server that maps a com- replication to insure that the appropriate authorized mtor- 
munity of domain communications servers together. mati on at each site is the same. Note that each customer is 
Similarly the domain routing of the present invention can not necessarily authorized to have access to all the content 
also be used internally to create additional domain commu- m the domain. In fact, the present invention is specifically 
nications servers to offload workloads from each other in designed so that access to content throughout the domain 
large internal networks. For example, companies having can be directed and controlled. Also in a preferred embooi- 
client side communications servers at several locations m mcnl a client side communications server CSS for a given 
the US and in Europe, might choose to have the European customer must use a domain communications server to 
client side communications servers connect to a domain 3q commun icate with other customers that are external to it. 
communications server in Europe which is mapped into a Referring now to HG. 5, a schematic diagram of several 
corporate domain communications server in the US, which, clieQts in communication with a domain communications 
in turn, might be mapped into external domain com mum- scrvcr ^ sa own. As can be seen, client C8 has the address 
cations' servers as described above. Using domain commu- of domam communications server Al on local disk OS 
nications servers internally to offload work can improve the ^ couplcd to client C8's computer 20, in which client side 
response time and throughput throughout the network. communications server software CSS8 is executing. Note 
-Riming now to FIG. 3, multiple connections of domain also in FIG. 5 that domain communications server Al 
communications servers are shown. Here domain commu- includes a computer 20, and a local storage media in this 
Sons s^er M which may be acting as the primary case, disk 40, having a dynamic client registry 06 stored m 
domaio communications server for a network of clients, can 4Q it . Also at domain communications server Al it can be seen 
ako be STernate domain communications server for the that a conventional Webserver WS is executing in compute 
ne^orlTcontrolled by domain communications servers A2 2 0, together with a conventional database ^nagemen 
or^ ofbXllternatively, domain communications serv- program DBMS. In a preferred embodiment of the present 
m A2 an d A3 mieht be regional domain communications invention, domain communications server sottware u^> 
sfrvefs fof I fiffiS^ conttolkd by domain commu- 45 also executes in cooperation with Webserver WS and data- 
mations Lrvet Al base software DBMS. It can be seen that domain commu- 

FIG 4 at a client C8's Boston location, C8-BO, a computer client registry 06 on disk 40. 

lotshowconncctedtodomaiccommunicationsservcrAl 50 In a preferred embodimen , web server WS K the 

hTh^rewall F8 and also to client C8's Local Area AOLserver product from America Online, as it also allows 

5^^SL^.^£S^cnt of the present the use of object-oriented technology. In open systems such 

i^tion Arnerica Online Corporation's standard Web- as Unix and similar operating systems, shared objects can be 

™ Lftw^e WS known as AOLserver™ is installed at created in the C ++ language. In the C ++ programming 

coTnuterT S ^^TCP^IP aimmunication protocols ss language, a shared object is simply compiled code^ 

be^en computer^ 1 firewlll F8 "and the Internet as well AOLServer has the ability to dynamically initialize shared 

EES-. <™ - >— BR on the term.als ^"^^^1^ 

"aI will be apparent to those skiUed in the art, any ^'^gS^S 

Webserver software or similar program that handles general » *° 

communications protocols and transport layer activities form ^of .he *£^> ^ amma . 

could be used as appropriate for the network, protocol m ^se ina preferred embodiment is the Illustra 
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computers to workstations or personal computers. Preferred 
embodiments of the present invention are designed to work 
with a number of existing installations as "middleware"— 
meaning software that does not replace or substitute for the 
existing operating system software or the typical basic s 
communications software. Nor is it a substitute for applica- 
tions software, such as the web browser. Instead, it works in 
the "middle." 

In a preferred embodiment, the nature and extent of a 
domain can be determined by several different factors. 10 
Since, as shown in FIG. 5, the domain communications 
server can connect the intranets of several different compa- 
nies or institutions in ways that allow them to operate 
together very closely, it is anticipated that one company 



registration, in this case. In many cases they also point to or 
include an object. 

Also in a preferred embodiment, client side communica- 
tions servers that are in the same firm or client can com- 
municate with each other, even if the domain communica- 
tions server Al normally used by that client is not active. 
Returning briefly to FIG. la, to illustrate this, for client C2, 
client side communications servers C2-HK, C2-NY and 
C2-LN can all communicate with each other inside client 
C2' s wide Area Network C2WAN even when domain 
communications server Al is not yet operational. 

That is, internal users and groups that have been estab- 
lished according to the method and apparatus of the present 
invention and authorized to create and view content can 



together very closely, it is anticipated tnai one tump<uiy invention ana auinonzcu iu umi 6 <^ w«« — 

might operate the domain communications servers for an 15 com municate with each other using the present invention 
industry segment, while the companies that are part of that ^ its organizing and indexing features even when domain 
segment would have their own client side communications communications server Al is offline or down. Messages that 
servers In FIG 5, for example, domain communications would normally have been sent by the client side commu- 
server Al might be a computer system for the investment nications servers at client C2 to domain communications 
banking industry segment of the financial industry, located ao server Al are queued and sent whenever domain commu- 
at applicant's Assignee's corporate headquarters, while cli- n i C ations server Al is started up. As will be apparent to those 
ents C1-C8 might be investment banks and investment sldUed ^ the art, other methods of providing for the corn- 
management firms. munication between the client side communications servers 
AswiUbeappaienttothoseskilledintheart,however,the and the domain communications server ^ 
industry segment might be law or automotive manufacturing 25 desired, such as requiring the domain communications 
oVDha^Sals or any of a number of other major or ser ver to be operational before the client side oommuiuca- 
mta?K^SeT If the industry segment is uons servers are allowed to communicate with each other, 
automotive for example, domain communications server Al Ghent side communication server startup 
mSbc ^operated by* service company, so that automobile Timing now to FIG. 14, an overview 
manufacturers might be able to communicate closely with 30 initialization of a client side communications server is 
mduuidciun,ia g, ^ nnitates the startup of a new 



suppliers and dealers. Still using FIG. 5, in this example, 
clients CI and C2 might be competing automobile manu- 
facturers and clients C3-C5 might be major parts suppliers, 
while clients C6-C8 might be dealers. En a preferred 
embodiment of the present invention, manufacturer CI 
could communicate closely with suppliers C3, C4 and C5, in 
a secure fashion, while manufacturer C2, its competitor, is 
also communicating closely with them, as well. 

Still in FIG. 5, in a preferred embodiment of the present 



shown. At step 400, the user initates the startup of a new 
client side communications server. At step 402 a server 
shared object is created, followed by client side server 
shared objects, admin server shared objects, tools server 
35 shared objects and agent server shared objects as created in 
steps 404, 406, 408, and 410, respectively. Once the shared 
objects have been created as shown in Step 412 of FIG. 15, 
processing continues. In FIG. 15, at step 414 the URL's used 
by the client side communications server (the principal ones 

» ... .. .. r» I \. '.,t^~^A unfh Tiro hi cprUPT 



^\{\\ in FIG 5 in a preterred emooaimeni oi ine pic&cm oy iuc tucm v^*"^™ x * * 

JSS U shou d be noted that domain communications 40 of which are listed in FIO K») are 
invention, auuui P1 ^ , vc w ^ wnr w niin nhiects are created at step 416. 



UJVPUUUU, LI «w ~ - — 

server Al and client side communications servers Ul-cs 
can each start up and shut down independently of each other. 
For example, the computer 20 which is part of domain 
communications server Al might be booted (started up) by 



WS. Next, workgroup objects are created at step 416. 

Another view of this is shown in the flow diagram of FIG. 
16 As seen there, at step 420, a client side communications 
server is initialized, then, at step 422, it registers its URLS 



rnmmiinications server Al migm oe oooico ^i<uiw up; uj ^tvti « ^"^'^ — > » — - —r ' * . in a» 

i^lf Tmmunicafion with the client side com- « with the web server WS executmg on * .computer ^20 At 

n&eii, wimuui anj ... * • „„i A*>A .h* Mi^nr c de communications server calls tne 



munications server. When that happens, domain communi 
cations server Al initializes itself and checks to see if there 
are any messages for it. If not, it will wait until one is 
received. Each of the client side communications servers 
C1-C8, may have their computers boot at different times, 50 
too. For example, if client side communications server C8 J s 
computer 20 is booted before domain communications 
server ATs computer is booted, client side communications 
server C8 initializes itself, and attempts to register itself with 
domain communications server Al, by sending messages 55 
containing the appropriate Uniform Resource Locators) 
(URL(s)) described below, for registration to domain com- 
munications server Al. If domain communications server 
Al has not yet been booted, these messages will be queued 
by client side communications server C8 and sent again 
later, in a preferred embodiment. As will be apparent to those 
skilled in the art, the registration messages could simply be 
regenerated at intervals, instead of queued. 

In a preferred embodiment, the URLs sent by the client 
side communications server and by the domain communi- 
cations servers usually contain at least the name of a 
function to be performed by the recipient, such as 



60 



step 424 the client side communications server calls the 
Register function on the domain communications server. At 
step 426, the domain communications server calls the 
adhocContentProducers functions on the client side com- 
munications server, and then, at step 428, the client side 
communications server calls the Producers function on the 
domain server. Next, at step 430, the domain communica- 
tions server calls the adhocContent Consumers function on 
the client side communications server, and finally, the client 
side communications server calls the indexes function on the 
domain communications server. 
Domain communications server startup 

With reference now to FIG. 20a, a very simplified over- 
view of the initialization of the domain communications 
server is shown (more detail is provided below.) At step 500, 
the domain communications server initializes itself and the 
dynamic client registry 06. Next, the domain communica- 
tions server checks, at step 502 to see if there are any 
messages (such as requests to register coming from a client 
side communications server). If there are no messages, the 
domain communications server could wait until there is 
some activity. (As will be seen below, in a preferred 
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embodiment, the domain communications server actually 
checks periodically to see if client side communications 
servers are still active.) 

Still in FIG. 20a, if a message has come in, such as a 
request from a client side communications server to register 
itself with the domain communications server, the domain 
communications server handles the message at step 504 in 
the manner indicated by the message itself, as described in 
more detail below. 

Client side communications server dynamic group registry 
Referring now to FIG. 20&, a flow diagram depicting the 
process used by a client side communications server to 
initialize or update the dynamic group registry 07 is shown. 
Starting at step 800, a user would give the group to be 
entered into group registry 07 a name, then, at step 805, 
indicate whether the access type for this group is to be 
common or restricted (these terms will be described in more 
detail below.) Next, at step 810, the client side communi- 
cations server checks to see whether this group will want 
base content (identified by subject), in which case at step 
815 base content is selected, or adhoc content (identified by 
source) in which case adhoc content will be selected. As 
described in more detail below, other types of content are 
also used in a preferred embodiment— mixed content and 
nondecoupleable mixed content, as well as system content. 
Processing for these is similar. As will be apparent to those 
skilled in the art, content can be grouped in any of a number 
of ways without deviating from the spirit of the present 
invention. 

Still in FIG. 206 at step 825, the client side communica- 
tions server configures a content list. In one preferred 
embodiment, the client side communications server next 
checks to see, at step 830, whether a rolling link format is 
desired or a fixed link one, and at steps 875 or 840 update 
the content list to list a title and indicate the number of rows 
to display according to the format. Then, at step 845, the user 
indicates the subject and /or the source of the content to be 
displayed on this content list in this group in dynamic group 
registry 07. At Step 850, the user chooses the authoring 
members, at step 855 the viewing members and finally, at 40 
step 860, the user can review the group's configuration. 

FIG. 21 is a flow diagram showing how the client side 
communications server determines whether to create client 
side communications server shared objects (compiled C++ 
code) to communicate with other client side communica- 45 
lions servers either inside (see steps 905 and 910) or outside 
(see steps 915 and 910) its own firm. 

FIGS. 22 through 26 are block diagrams of the interactive 
screen displays created by the present invention for use by 
a browser BR at a terminal. These figures are illustrative of so 
the steps described above to create groups on the dynamic 
group registry 07 in a preferred embodiment of the present 
invention. FIG. 22, for example, shows how a user might 
enter a new user's name, and FIG. 23 illustrates how account 
information specific to that user can be entered, such as 55 
usemame, and so on. 

FIG 24 shows how the client side communications server 
begins the process of establishing authoring rights 
(described below in more detail.) FIGS. 25a and 25b illus- 
trate an example of one way of organizing content 6( 
geographically, by global region. As is indicated, the user is 
asked to indicate his or her selections for these choices. 
Next, in FIG. 25c, sample distribution options are shown. 
Next' in FIG. 26a, the client side communications server 
allows the user to specify whether the new group member 
should have redistribution authorization (this is described 
below in more detail.) If this is to be allowed, the user can 



specify, as shown in FIG. 26fc, whether this redistribution 
right extends only to internal members on either a limited or 
unlimited basis or to external members, on either a limited 
or unlimited basis, 
s Next, turning to FIG. 26c, a sample screen display asking 
whether the new member is to have access to any restricted 
groups is shown. If the user said yes to that screen, FIG. 26d 
shows how the user might be asked to specify to which 
restricted groups the new member should have access, and 
io also in what capacity— that is, as a viewer or a contributor 
or a redistributor or an administrator, or all or some com- 
bination of these. 

In FIG. 26e, a sample screen display asking the user to 
specify what kind of external group access the new user 
should have is shown. Relating back to the example of the 
financial community, it can be seen in the display shown m 
FIG. 26e that it is a very simple matter to "permission" a 
new member to create and distribute documents to other 
participating companies— firms CI, C2 and C3. in the same 
intelligent extranet. 

Once the user has finished answering the questions about 
adding a new member, the client side communications 
server completes the updating of the dynamic group registry 
07 to reflect these changes. 

As will be apparent to those skilled in the art, a client side 
communications server can be a self-sufficient entity, used 
simply to provide a much better and simpler intranet man- 
agement tool inside a corporation than presently exists. The 
client side communications server also acts as a powerful 
30 publications control. By simply answering the questions 
brought up on the screen displays as new members and 
groups are added to the client side communications server 
the user is able to organize, index, and control more than 
ever before the creation and dissemination of information 
amongst the individuals and groups known to the client side 
communications server. 

Returning to the financial community example shown in 
FIG. la, if this client side communications server is installed 
at bank C2, (of FIG. la), which has branches in Hong Kong, 
New York,'and London, it can replicate itself so that there is 
a client side communications server C2-HK in Hong Kong, 
a client side communications server C2-NY in New York, 
and a C2-LN in London. The procedures described above 
can be used to manage communications amongst all three 
internal sites in a way that provides organized, fast access to 
the information created inside bank C2. As will be seen from 
the discussion of indexing below, a viewer in London can 
ask for and see indexed information he is authorized to 
receive, comment on it internally, and have those comments 
reviewed by his peers in Hong Kong and New York, if he has 
those kinds of redistribution rights. 

Now turning to FIG. 6a, typical client information kept by 
a domain communications server Al in a dynamic client 
registry 06 is shown. Dynamic client registry 06 includes a 
55 domain clients table 60 (here shown in abbreviated form) a 
domain clients sources list 66, domain client objects table 62 
and domain client objects destination list 68 and an index 
table 64, as well as a channels table 61, a channel content 
table 63, and a channel template table 65. A domain clients 
60 table 60 fists aU the client side communications servers 
within the given domain. As noted above, a client may have 
more than one client side communications server (for 
example, where the client has multiple sites across the 
world, as in the case of Clients C2 and C4 shown in FIG. 

65 ^Consequently, as shown in FIG. 6b in a preferred 
embodiment, an entry in a domain clients table 60 of 
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dynamic client registry 06 slides, for each clieo, server SSSS^S 
the unique client side comrm.mcat.ons .server name 60a an ^ C ^V° rus ^ v ^ ^ umversaUy 

indicator 606 which shows whether the server is active or be ^^Sobe Acrobat™ PDF format, or in a formal 
not, a unique firm identifier 60c, which indicates the name r word cessjng program as Microsoft 

of the company or firm or client that owns this server, a firm 5 Wo ^ TM Qr Wordperfect™, or a spread sheet pro- 

logo 60e, which can be reproduced in visuals associated with ^ ^ Microso£Vs Excel ™ or IBM's Lotus 1-2-3™ 

this firm and a domain client side identifier 60/, which, in a * dshcels . Similarly, if a firm already has existing HTML, 
preferred embodiment, is the server location within the fo rma tted pages, these, too can be objects. It should be noted 
firm's intranet, which, when combined with the firm iden- ^ in a prefcrred embodiment of the present invention, the 
tifier field 60c, creates a unique key. As will be apparent to 10 o) . c|s which are me of all the communications can 

those skilled in the art, more or less or other information for aU pract i ca [ purposes, be in any format. For example, an 
about each client side communications server could also be object mignt a iso b e as complex as a full color movie wiUi 
included here if desired. For example, in addition to a logo, sound> or a CAD/CAM VLSI drawing of a chip set or 
r^rhaos an address of the firm's Web Page on the World engineC ring drawings of an automobde under development 
w L Web could be included. Alternatively, a logo field or is f n the latter examples of CAD/CAM or engineering 
J^^^^S* address field, far example, could drawin gs, which are also usually ^««^^» 

^ to FIG. 6. in a p.ferred M tSSEX^S 

A domain client source list 66 is a list of all connections toed embodmie U ' P ^ afe trans . 

between client side communications servers within itte sock* ^« ™ SQcket technology , at 

domain. Still in FIG ,6a, and using ^^XlTZ 25 Xe prSng cli^t side communications server, and 

example, if competitors Cl-PA and C2 are tvoatu* 25 tL^a at the receiving client side communications server 

competing manufacturers and C3 is a J cS futhorized to receive them. In a 

of them, then domam cUent sources list 66 might ^be suric °' f ° „y ^ bodiment( m is encryption and decryption of 

tured as shown. At column 66*, unique JSSJSbteSTis an automafc byproduct of the use of 

DSCfirmlD's are listed next to each source DSCsourceF.r- ^bgy and its equivalents or improve- 

mlD in column 66b. Thus, company Cl-PA can receive 30 secure sockete to mose Lued in the art, other 

content from itself, Cl-PA, as well as from ^to^XquS could be used instead of secure socket 

that company Cl-PA is not shown as being g ™ U ar technologies. For example, techniques such as 

receive any source information from its compettor, O- ^"ry^on usmg software such as PGP, which is based 

Similarly, company C2 can receive source content from , i( f n A gorim ms could be used, 

itself and from suppUer C3, but not company Cl-PA This 35 on (he RS^ypUon g ^ ^ fa ^ 

illustrates how the virtual pipes described above are formed. Still m wo j q 

Still in FIG. 6a, a domain client objects table 62 is shown, ™£"™B . ^S^«S*«Lnt 62c, a movie 62* 

as well. The domain client objects table contains all distrib- »n«M ferted embodiment of the 

uted objects received by the domain communications server •^^^Jg^ a ° e presented either as text or as 
from any valid client side communications server within the 40 P ^^^^"^Xsai text format report 62« will 

given domain. Upon receipt of such an object, the domain files. Thus ; the first to^SU ascjtV*. ah the 

fommunications server notifies all client side communica ^S^^aT^bject. table 62 are handled 

tions servers having authorized access to that object that an oU> er objects £ d °™ m ^ presentation 62i», for 

object is available to be retrieved. Each entry m me domain s Me ^ n «J^« J^^tfons server 

client objects table 62 points to a different domain client 45 example .Us *ansm^ ^ ^ ^ 

object destinations table 68 that lists all the client side ^ jj^^ ^^ation servers as a file, too. 

to the distributed content that will be sent to the client side server for toa cteated ^ 
communications servers. Referring briefly to FIG. 6b, with S P™£°S " ftware , the viewer at the client 
a domain client object destinations table entry the domain Microsoft * Powe^mt *>ft ^ ^ ^ 
cUent target table 68a lists all the server names of the client site must * ( a ™ » j mjs can be done by 
side communications servers to which » «?; 55 ? ^ TtTe application software installed at the 
lined. The domain client received column 68c contams, for havuig a copy ™ servin this 
eachtargetedclientsidecommunicationsserver metimethe emimal ^] ^ but „ advantage , 
object was received by the domain communications server *™ m f ^ ™* b ^els personal computer users there are 
The domain client processed table 68d contams for each ^^^J^^ff^^J^ ach ieved near 
client side communications server, the time the object was 60 ^^^^^ l J C weh „ word processors, spread- 
processed by the client side communications server In a ^^^ B ^J^^ nn , As wfll be apparent to 
preferred embodiment, this field is initially set to Null and ^J^J^^^L invention allows the users 
updated whenmeclientsidecommunicauonserverretneves ^^^^^^ products and even spe- 

^rnlngtatS^a inapreferredembo^^^^^ 

SrexX^ SgTp-LsoftwLandpriordeveiopmen. 
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Still in FIG. 6a, an indexes table 64 is also shown as part 
of dynamic client registry 06. The indexes table 64 is used 
to organize the domain's content. The values of the indexes 
are the same for a given domain. As shown in FIG. 6a, 
illustrative indexes for the investment banking market seg- 
ment domain are shown, including Mortgage, Agency, New 
Issue, Research and other indexes that might describe the 
content of the domain in an orderly fashion. 

Referring now to FIG. 66, an index entry is shown having 
an IndexID 64a, an IndexDescription 646, an IndexBasctype 
64c, and an IndexParentID 64<f. Index ID64a is the unique 
identifier of the index. In a preferred embodiment, Index- 
BaseType 64c is used to determine which type of format 
(text or file) is used as the default format for that index, but 
all content for that index can be of both types. IndexDe- 
scription 646 is the descriptive label applied to the index. 
And IndexParentID 64d is the IndexID of this entry's parent. 

Turning back to FIG. 6a again, in indexes table 64 it can 
be seen that Index 11, New Issue, is a "child" of index ID 1, 



With reference now to FIG. 7a, illustrative structure and 
contents of dynamic group registry 07 of the present inven- 
tion are shown. In a preferred embodiment, dynamic group 
registry 07 is used at each client to handle all the content that 
s is produced internally at that client as well as the content that 
is produced throughout the domain that is received by that 
client. As noted above, each client side communications 
server must use the domain communications server in order 
to communicate with another firms' s client side communi- 
io cations server. . 

As shown in FIG. la, the principal entry m client side 
dynamic group registry 07 is group table 70. Group table 70 
is a list of all groups that have been established within a 
particular firm or client. Note that, while the term workgroup 
15 may occur in the figure or this text, the term group is 
generally preferred and can be read interchangeably. A group 
is used to organize the type and source of the content (as 
specified in content table 90 and ad hoc content table 94) 
available to that group and creates the respective content 
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New Issue. In a preferred embodiment, indexes can have as 
many levels as needed. 

Still in FIG. 6a, in a preferred embodiment, channels table 
61, channel content table 63 and channel templates 65 are 
also created. In a preferred embodiment of the present 
invention a channel is a combination of various indexes. For 
example, one channel might consist of all the indexes that 
are likely to contain hot news items. Another channel might 
be composed of those indexes that are most frequently used. 
As will be apparent to those skilled in the art, the number 
and content of such channel groupings might vary from 
industry to industry or over time. As can be seen, then 
channels table 61 is used to organize the domain's content 
into related categories. These channels are then passed to 
client side communications servers upon startup and are 
used during the setup and administration of groups. In an 
alternative preferred embodiment, this function can be 
included in the client side communications server or a client 
side communications server using a domain communica- 
tions server for internal purposes. 

With reference now to FIG. 6b, channels table 61 contains 
a channel id field 61a, a channel name field 616, and a 
channel description field 61c. For hot news items, a channel 
id of 1 might be assigned, with a channel name of "Hot 
News Items" and a channel description such as "hot news 
from the New Issue, Mortgage and Research indexes." As 
will be apparent to those skilled in the art, if the domain is 
in another industry segment, such as automobile 
manufacture, the indexes and channels will refer to different 
topics and combinations of topics. In a preferred 
embodiment, channel content table 63 is used to determine 
the content that makes up the channel. Again, in FIG. 66, 
channel content table 63 contains channel id field 63a, 
channel content id 636, which is paired with the channel id 
field 63a to create a unique key, a channel type field 63c, 
which will indicate whether the content is base content or ad 
hoc content or other types (as described below), and a 
channel content source field 634 which indicates one or 
more sources for the content for that channel. In a preferred 
embodiment, a channel template table 65 is used to organize 
the channel's content. Each template contains a channel 
template id field 65a, a channel template field 656, which is 
paired with channel template id field 65a to create a unique 
key, a channel template attributes field 65c which defines the 
attributes of the content list, and a channel template sources 
field 65a 1 ,, which refers to id's found in the channel content 
table 63. 
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table 90 organizes content by the object id 90a, the author id 
906, the content link object id 90c, the content headline 90d, 
the content filename 90/, the content information 90& the 
content timestamp 90/t, the content origin site 90*, the 
content origin object id 90j, and the content data attribute 
90Jt. This is automatically added as it is produced to all 
groups that have requested that specific type of content. Ad 
hoc content table 94 organizes ad hoc content by the source 
of the information and is added to a group when the author 
(or publisher) directs the ad hoc content to that group. 

As can be seen in group table 70 of FIG. 7a, in a preferred 
embodiment there are two types of groups—common and 
restricted. A group that is common is accessible by all 
viewers within the client or firm and can only take base 
content. Restricted groups are viewable only by members of 
the group as specified in the workgroup view members table 
82. A restricted group allows for both base content and ad 
hoc content as well as other types of content that may be 
developed. Ad hoc content can only be added to the group 
by the group's author and publisher members (workgroup 
author members table 80 and workgroup view members 
table 82.) 

Still in FIG. 7a, in group table 70, it can be seen that m 
a preferred embodiment, all groups have a community, 
indicated in the field WGcommunity, in which they are 
"known." The community is used to 'advertise' to other 
groups within the firm or client. The community contains 
producers of content that is advertised either internally (to 
the firm or client only) or externally to the entire domain. An 
internal group is not known outside of the firm or client. An 
external workgroup is known inside, as well as outside, the 
firm or client. If a workgroup is set as a producer, by using 
a value of 2, in a preferred embodiment in the WGcommu- 
nity field of group table 70, the group is advertised as a 
source of ad hoc content for other groups. 

Still in FIG. 7a, in a preferred embodiment, groups that 
are solely internal to the firm or client are so indicated by 
using a 0 in the WGcommunity field of group table 70. As 
shown in group table 70, workgroup WG1, a firm wide 
group, is the only internal group listed in this particular 
example. External groups are indicated by the use of a 1 
value in the WGcommunity field of group table 70. In setting 
the values for the WGcommunity field, a preferred embodi- 
ment exclusive OR's the values to determine all choices. In 
a preferred embodiment, the WGgrouplD's are always 
unique since they are composed of a firmid, a site id and a 
number. As will be apparent to those skilled in the art, any 
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of a — ofwaysc.n.eusea.createun^e^por * ^ * 

IRai., workgroup base content table 74 i. used L^^Sft 

to determine the base content the respective ™^P» ?™ P ^ 

interested in receiving when such content is P^d^d either 5 ^^^JbKiD. THat is, ABgroupID is the 
internally or externally. Base content is selected by the group i*dm» ^ P ^ hflS ermissione d the 
content type, (the index value WGBOndexID) and car, be unique to totribut/thc workgroup's 
received by both common and restricted ™k6W^P°n ^^^^^S to the GroupID of the group 
receiving a particular content type, the workgroup s content content. dcstinaUon ficld ^destination con- 
list headlines are updated, ^^.iwievt 10 tains the flrmlD and the workgroup ID of the group to which 
Workgroup master lists table 76 prov!des descriptive text ^J^^^ ^ di f trit £ tc content. Address book 

^^St^Jtorkgnmp ad hoc content table 78 attribute field ABattribute of address book table 84 is in a 

• ^ !n rle^ne the ad^ hoc content the respective preferred embodiment, a Boolean value set to true if the 

workup tS£Z*L re'eeWm^when such cogent is workgroup allows this author or publisher to add a note to 
nroduced either internally or externally. Ad hoc content is ™ &c content, and to false if not. 

dSeSd^^souic/of the content as opposed to the Remaining in FIG. 7a, author rights table 88 is usedto 
Index of the content. The sources for ad hoc content are determine the type of content a given author can create. The 
those eroups that have "advertised" themselves, as described table stains three fields: author identifier AuthorlD auUior 
above Mixed content is a combination of both adhoc and ^dex idenu fier AuthorlndexID, and author attnbute Author- 
base content on 20 Attribute. In a preferred embodiment, the content type (as 
Also in FIG. 7a, workgroup author members table 80 mdic ated by the author attribute field) that an author can 
contains the list of authors and the groups that have specified fe determined by the firm or client. This allows the 
they wiU allow this author to add ad hoc content to the to define and ^p^ent its own internal policies for 
respective group. The authors are chosen from the list ot ^ ma than obligat i n g the firm to abide by 
authors within a firm or client. The groups are also from toe M ^ estabUshed by others or me constraints of a par- 
list of groups within the firm or client. Entries into this table f external system. All authors must be valid viewers of 
will only exist for groups that have specified that they are ^ ^ ^ 

producers of new content. In the example of the workgroup preferred embodiment, all authors have a minimum 
author members table 80 shown here, there is a workgroup f fc ^ brQadcast for me speci fied con- 
author identifier WGAMauthorlD. This field is linked to the 30 preferred embodiment, the possible values 
ViewerlD of the viewers table described below. A work- ™i iyp . 
group author members group identifier WGAMgroupID are - 

identifies the unique group within this client to which this 

member belongs. This value is linked to the WGgroupID ot utcTOsl Broadcast 0 

t . i 35 Internal Selective 1 

TnCetmple shown in FIG. 7., the same author, tburns = * 

is listed as a member of workgroup 2 WG2 and workgroup ™ . 

i w/n'X The field workgroup author member restrict 

WGAMrestrict is in a preferred embodiment, a boolean nese va i ues are exclusive OR'd to determme aU [choices in 
™£e«K set to true if the author must have been w a pre ferred embodiment. As wiU be apparentto those skilled 

S^ily "pwmiMioned- to send to each of the work- ^ art , other ways of defining and .mplementing such 

groups that consume this workgroup's content. If this value vahles could be used 

1 set to false, the author can send to any workgroup that still in FIG. 7a, viewers table 86 ^ " 

consumes this eroup's content. valid users or viewers at a given client or firm. This table is 
sXk HG 7a workgroup view members table 82 45 ,^ dto determine if the specified user or viewer B a membe 

contains me list of viewers for the workgroups. Only viewer of me client's intranet and access to that <^»£™^ 

members of a workgroup have view access to a workgroup's oaly be allowed if the user or viewer is listed in .this itAte. 

° nTent AO vieweT members of a workgroup are selected xjsers or viewers entered in this table are allowed access to 

from tne lJ of valid viewers for the firm or client. A & client or firm workgroups that are common, as specified 

workerouo administrator (as specified in the WGVMadmin so m ^ WGmembership field of group table 70 

i:^:"L^in, members and the attributes of Tuming DOW to FIG. 8a, and back .to a » 

any members for the group. Distribution of the group's domam communications servers, a hst of the pn°cipal 

contenfrconuoued by me viewer attribute field WGVMat- domain communications server URU >s ?™n. men- 

tribute In the example shown here, viewers tmalone and tione d above, a domain commun.calions server is 

bur^ of workgroup 2 WG2, are administrators for work- 55 implemented, in a preferred ™ b ^ a \™™* AO }^™ 

sZ? 2 WG lln a preferred embodiment, there are five sot We, because of its ability to dynamicaUy lo^ared 

valuL that may be set for the viewer attribute field WGV- objecls when spawning a virtual server. In a preferred 

Attribute TtaeW embodiment of the present invention, obiect-onented pro- 

Mattnbute. These are. gramm ing techniques are used, since they allow the creation 

60 of procedures for objects whose exact type is not known 

Distribute None ° unt ji actual running of the program. Object oriented tech- 
Distribute Internal I nioues also permit the system implemcnter to define and use 
3SK S Restricted 4 shared objects^ompiled C ++ ^^J^^^ T 
Distribute External Restricted 8 lharj one function or program. In the AOLscrver, tor 
— 65 example, which shared object to load is specified to it withm 
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the shared object named 'domainserver.so* (also known as 
'domainserver.dll' for NT versions), is designated as the 
shared object to be loaded when the AOLserver is started up. 

In a preferred embodiment, the AOLServer Applications 
Programming Interface (API) is used because it is an inter- 
face which allows for the development of shared objects 
which can be loaded by AOLServer. The API is ANSI-C, a 
standard programming language interface and therefore 
requires C++ wrapper functions in order to bridge between 
the C based AOLServer and C++ based domain communi- 
cations server's objects. There are two wrapper functions 
denned by the domain communications server, named "go 
and "stop". As will be apparent to those skilled in the art, any 
server or program which provides similar functionality 
could be used instead. 

The AOLserver NSD parent process, when starting any 
virtual servers, will look for a function named 
NS_ModuleIoit which (per AOLServer documentation) 
must be defined for all shared objects that are loaded and 
contain any required start-up code. The domain communi- 20 
cations server of the present invention's Ns-Modulelmt 
function has two responsibilities, first to register the shut- 
down procedure "stop" that will be called by the parent NSD 
when shutting down secondly, to call the C++ wrapper 
function "go" which creates an instance of a DomainServer 25 
object. The shutdown procedure "stop" is responsible for 
cleaning up the DomainServer object initiated by calling 

"go"- 

As described above, a domain communications server 
according to the method and apparatus of the present inven- 30 
tion is responsible for distributing and collecting content 
from various client side communications servers v/ithin its 
domain. It will also control which client side communica- 
tions servers may communicate with each other and act as 
"switching point". . 35 

The creation of a domain communications server is ail 
that is required by the wrapper function goo. When creating 
a domain communications server object the following steps 
are taken: 

First the domain communications server saves local van- 4C 
ables that specify (among other things) the "recognized" 
name of the virtual server and access to the underlying 
database manager. 

Next, the available categories used by the domain to 
organize all of a domain's content are loaded from the table 4: 
Indexes, (see FIG. 6b) and are stored internally as Index 

Objects. . 

Third, the domain communications server determines all 
valid domain clients that are known to be within this 
domain, their network addresses, and which clients can 5 
communicate with each other— the virtual pipes (as shown 
in FIG. la.) Valid clients, client side communications serv- 
ers and their respective virtual pipes are found within the 
tables DomainClients and DOientSources and are stored 
internally as DomainCUent Objects. 5 

Fourth, the domain communications server will determine 
the predefined templates used by the domain's clients when 
creating new groups at the client side communications 
server sites. These templates are used to organize the 
domain's Index Objects and network producers into a more < 
organized format when setting up what is consumed by the 
client side communications servers. The information for 
these templates are found within the tables Channels, Cban- 
nelContent and ChannelTemplates shown in FIG. 6a and are 
stored internally as Channel Objects. 

Lastly, the domain communications server will register 
with the AOLserver parent NSD process the URLs (Uniform 



Resource Locators) shown in FIG. 8, that the domain 
communications server will handle and the corresponding 
callback function in the domain communications server that 
the AOLserver parent NSD process should call when any 
such URLs arc requested. These registered URLs are used to 
communicate between the domain communications server 
and any valid client side communication server within the 
domain. Information is passed between client side commu- 
nications servers and the domain communications server via 
these registered URLS as a result. All information passed is 
in a form known in the art as "persistent objects" (i.e. objects 
that can restore themselves from stream form) and are 
retrieved and/or distributed via a respective URL. 

The following is a list of the URLs and allowable methods 
that are registered and the event class associated with each 
in a preferred embodiment: 



Method 



Event Class 



/Register 
/Indexes 



/Consumer 



/Producers 



/Channels 



/Un register 
/Status 

/DistributeObject 

/CollectObject 

/Refresh 

/Firm Logo 

/InternalScrveis 

Statua/Reloadlndcxes 

/Status/CSSStatus 



GET 
GET 



GET 



GET 



GET 

GET 

GET 

GET 

GET 

GET 

GET 

POST 

GET 



CSS Registration 
CSS Registration 
and 

Registry Change 
CSS Registration 
and 

Registry Change 
CSS Registration 
and 

Registry Change 
CSS Registration 
and 

Registry Change 
CSS Deregistration 
Status 

Content Replication 
Content Replication 
Registry Change 
CSS Registration 
CSS Registration 
Status 
Status 



After startup, the domain communications server will 
then schedule a timer procedure to check every 60 seconds 
the current status of each valid client side communications 
server in its domain and "ping" those for which no activity 
has been recorded within the last five minutes. In a preferred 
embodiment, a ping is simply a message requesting a status 
be returned from the client side communications server. 

An example of a domain communications server attempt- 
ing to ping a client side communications server might look 
tike: 

https://validCSS.com:84/Ping 

In response to this URL, the client side communications 
server in a preferred embodiment will return the HTTP 
status code 200 signaling the domain communications 
; server. The pinging of a client side communications server 
will determine its current status and ensure that it is up, 
running, and registered with the domain communications 
server. 

If a client side communications server responds to a ping 
3 message the domain communications server will check to 
see if the client side communications server is already 
currently registered and if it is not, it will ask the client side 
communications server to attempt to register at this time (or 
re-register if the client side communications server has been 
5 running longer than the domain server). If the client side 
communications server is currently registered the domain 
server will note the last time it contacted this client side 
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communications server and will not ping it again unless a lag 
of 5 minutes or more occurs before contact is re-established. 
If the client side communications server does not respond to 
the ping, the domain communications server will note the 
client side communications server as not registered and will 5 
attempt to ping this client side communications server every 
60 seconds until a response is finally returned. 

Once initialized, the domain communications server sim- 
ply responds to events that occur within the domain The 
domain communications server is responsible for verifying 10 
events as valid as well as notifying any client side commu- 
nications server of the effect of such event. This is done 
through the handling of the URLs specified above. 

The following is a list of the event classes and the 
corresponding actions that can occur within the domain: 
1. Client side communications server registration. 

The registration of a client side communications server 
with the domain communications server is started when the 
client side communications server requests the "Register" 
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In a preferred embodiment, the registering client side 
communications server will then request additional infor- 
mation about the domain using the other URLs handled by 
the domain communications server, as shown in FIG. 8a. All 
potential recipients are validated prior to returning any 
requested information. This information will include the 
following: 

The list of Index Objects used by the domain is requested 
by the Indexes URL 106 of FIG. 8a. Index Objects are 
used to organize content by subject matter (also known 
as base content) within a given domain and are hosted 
centrally by the domain communications server in 
dynamic client registry 06. Index Objects are used by 
the client side communications server as part of its 
dynamic group registry 07. 
The response to the Indexes URL 106 of FIG. 8a causes 
the domain communications server to iterate through its 



client side communications server requests toe "egjswr ^ j d 0b - ^ ^ retum them m stream form. 

URLfrom its domain communications server (the ; addres _of 20 col faack ^ Jndex 0bjects at the 



the domain communication server is found within the ini 
tialization file used when starting the domain communica- 
tions server). In a preferred embodiment, the format of this 
URL is "DomainServer:/Register?lD*=CSS" where Domain 
Server is the protocol, machine name (and port) to request 25 
from and ID variable is the CSS's protocol, machine name 
(and port). Since the protocol is specified in this manner, it 
is trivial for the domain to use either standard HTTP or the 
SSL layer. In an alternative preferred embodiment, the 
present invention implements the X.500 Lightweight Direc- 3C 
tory Access Protocol (LDAP.) 

An example of a client side communications server 
attempting to register might look like: 

https://myDomaLnServe.coin:8 l/Register?ID=https*7/vaIidCSS- 

. com :84 3i 

The domain communications server will then verify that the 
location specified by the ID is a valid location for this 
domain by checking its internal collection of DClient 
Obiects (loaded at startup). If the request were validated, the 



Ul v^^j^ ~ — 

The stream form is translated back into Index Objects at the 
client side communications server site and collected locally. 

An example of a client side communications server 
requesting the indexes might look like: 

httpsr/ZmyDomainScivercomiSl/indexeslID-https^alidCSS- 
.com:84 

The list of InternalServer Objects is collected by request- 
ing the IntemalServers URL 126 of FIG. 8a. Inter- 
nalServer Objects are used by a client side communi- 
cations server in determining the sites of all other client 
side communications servers considered to be of the 
same firm and hence the client side communication 
server's responsibility to replicate to and from. 
The response to the IntemalServers URL 126 causes the 
domain communications server to ask the validated Domain- 
Client to iterate through its collection of VirtualServerOb- 
jects and return them in the stream form. The stream form is 
translated back into InternalServer Objects at the cUent side 
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side communications server the "virtual pipes available to 
this client side communications server by passing a list of 
ClientSource Objects, from dynamic client registry 06. It 
can be seen that dynamic client registry 06 serves as the 
repository that enables the virtual community of intranets to 
be formed. 

In a preferred embodiment, validation requires that the 
domain communications server request the ContentProducer 
and ContentConsumer Objects from the registering client 
side communications server's site. The response from the 
client side communications server is the stream form 
(streaming is an input/output format for data used in most 
open systems) of the respective objects. The objects are 
recreated at the domain communications server and col- 
lected locally. It is the domain communications server's 
responsibility to determine which ContentProducers and 
ContentConsumers are available to which client side com- 
munications server by checking with the list of "virtual 
pipes" already established. 

An example of the domain communications server 
requesting a registering client side communications server 
for its ContentProducer objects is: 

https://validCSS.com:84/AdliocContcntFioduccis 
An example of the domain communications server request- 
ing the client side communications server for its Content- 
Consumer objects is: 
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client side communications servers of same firms are 
returned (this includes the requesting client side communi- 
cations server as well). 

An example of a CSS requesting the internal servers 

might look like: 

https://myDomainSeiver.com:81/IntenialServcrs=https://validCSS- 
.com:84 

The list of ContentProducer Objects is retrieved from the 
Producers URL 110 of FIG. 8a. ContentProducers are 
used by the client side communications server as part of 
the dynamic group registry 07 as available sources of 
adhoc and mixed content. ContentProducer objects 
contain the information about the producer and what it 
Produces. It is the domain communications server's 
responsibility to determine which ContentProducers 
are available to the requesting client side communica- 
tions server by checking with the list of virtual pipes 
already established. 
The response to Producers URL 110 of FIG. Sa causes the 
domain communications server to return in stream form the 
ContentProducers available to the requesting client side 
communications server from all other client side communi- 
cations servers within the domain. For sites of multiple 
internal servers the stream includes internal producers as 
well. The stream form is translated back into CootentPro- 
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ducer Objects at the client side communications server site 
and collected locally. m m 

An example of a client side communications server 
requesting the ContentProducers might look like: 

https://myDoirainScrvcr.com:81/Produc6rs?[D=https://vaHdCSS- 
. com: 84 

The list of ContentConsumer Objects is requested via the 
Consumers URL 108 of FIG. 8a. ContentConsumers 
are used by the client side communications server as 
part of the "domain registry" as to determine which of 
its producing groups have consumers requestmg their 

The°retponse to the Consumers URL 108 of FIG. 8a 
causes the domain communications server to return in 
stream form the ContentConsumers available to the request- 
ing client side communications servers from all other client 
side communication servers within the domain. For sites of 
multiple internal servers the stream includes internal con- 
suming groups as well. The stream form is translated back 
into ContentConsumer Objects at the client side communi- 
cations server site and collected locally. 

An example of a client side communications server 
requesting the ContentConsumers might look like: 

https://myDoimmScrvcr.com:81/Con S umcrs?[D-http://vaUdCSS- 
.com:84 



The list of ClientlnfoChannel Objects are collected via the 
Channels URL 128 of FIG. 8a. ClientlnfoChannel 
objects are used as templates for creating new groups at 
the client side communications server. The InfoChan- 
nel object organizes portions of the domain's content 
into preconagured views that ease the creation of a 
group at a client side communications server site. 
The response to the Channels URL 128 of FIG. 8a causes 
the domain communications server to return m stream form 
the Infochannel objects available to the requesting client 
side communication server. The stream form is translated 
back into Clientlnfo Channel Objects at the client side com- ^ 
munications server site and collected locally. 

An example of a client side communications server 
requesting the Channels might look like: 

hUps://myDomainS6Tver.com:81/Ciannels?ID-https://validCSS- 
.com:84 

The list of Logo Objects are collected via the FirmLogo 
URL 116 of FIG. 8a. Logo Objects are used to further 
"brand" content with the originator. The registering 
client side communications server wiU request for any 
Logo Objects it does not currently have a "current" 
Logo Object". Status of the LogoObject is determined 
from the list of ClientSource Objects received from the 
Register URL 102 of FIG. 8a. 
The response to the FirmLogo URL 116 of FIG. 8a causes 
the domain communications server to return in file form the 
corresponding LogoObject of the client side communica- 
tions server specified. The object is stored on the local file 
system and served whenever content that originated from 
this source is viewed. 

An example of a client side communications server 
requesting the LogoObjects might look like: 

https://myDomamStrvcr.oom.81/FirmLogo?ID-https:// 
validCSS.oom:84&SROhttps//myCSS2.com.85 

The registration of a client side communications server 
will trigger the domain communications server to notify all 



of the other client side communications servers (having 
virtual pipes to the registering client side communications 
servers) that changes in the dynamic client registry 06 have 
occurred that may be of interest to them. This will cause all 
s Registry Change events to occur at each respective client 
side communications server. The changes include the avail- 
ability of both additional consumers and producers found 
within the registering client side communications server. 
The notification is done by requesting the /Refresh URL at 
10 each client side communications server and specifying that 
both the /Producers and /Consumers have changed and 
should be refreshed at the client side communications serv- 
ers' convenience (see Registry Changes below for a detailed 
description). t • , j 

15 In a preferred embodiment, registration is always initiated 
by the client side communications server. HoweveT, also in 
a preferred embodiment, the domain communications server 
may ask any client side communications server at anytime to 
re-register when the domain communications server deems 
it appropriate. 

2 Client side communications server deregistration 

The deregistration of a client side communications server 
occurs when the client side communications server needs to 
notify the domain communications server that it will no 
is longer be available to the domain. This event is controlled by 
the client side communications server and can occur at 
anytime, but, in a preferred embodiment, will always happen 
when the client side communications server attempts to 
shutdown normally. The client side communications server 
30 notifies the domain communications server of its desire to 
unregister via the Unregister URL 104 of FIG. 8a. The 
format of this URL is Domainserver:/Unregister?ID«CSS 
where Domain Server is the protocol, machine name (and 
port) to request from and ID Variable is the client side 
35 communications server's protocol, machine name (and 

P °An example of a CSS attempting to deregister might look 
tike: 
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https://myDomainSeiver.com:81/Dcicgister?ID-https://validCSS- 
0 .com:84 

Hie domain communications server will then verify that the 
location specified by the ID is a valid location for this 
domain by checking its internal collection of DClient 
15 Objects (loaded at startup). If the request was validated, the 
domain communications server will return the HTTP status 
code 200 signaling the client side communications server 
that it is now considered unregistered by the domain. All 
content destined for this client side communications server 
so will be queued at the domain communications server until 
the client side communications server becomes available for 
the domain again. 

In a preferred embodiment, deregistration of a client side 
communications server may also be initiated by the domain 
55 communications server This can occur when a client side 
communications server does not respond to the /Ping UKL- 
requested by the domain communications server when a 
specified amount of time (usually 5 minutes) has expired 
since last contact from the client side communications 
60 server. As will be apparent to those skilled in the art, shorter 
or longer time periods could be specified for this interval. 
And similarly, while a preferred embodiment uses this 
approach, and queues messages for the client side commu- 
nications server deregistered for this reason, it will be 
65 apparent to those skilled in the art that other techniques 
might be used to cause the messages to be held for the 
non-responding client side communications server. 
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In a preferred embodiment, the deregistration of a client 
side communications server will trigger the domain com- 
munications server to notify all other client side communi- 
cations servers having virtual pipes to the deregistermg 
client side communications server that changes in the 
domain's registry have occurred that may be of interest to 
them. The changes include the unavailability of both addi- 
tional consumers and producers found at the deregistermg 
client side communications server. The notification is done 
by requesting the /Refresh URL at each client side commu- 
nications site and specifying both the /Producers and 
/Consumers have changed and should be refreshed at the 
client side communications server's convenience. 
3. Content replication 

This event occurs whenever content must flow from one 
client side communications server to another client side 
communications sever within the domain. It should be noted 
that in a preferred embodiment, the domain communications 
server is only responsible for content replication between 
client side communications servers of different firms 
(external replication). Content replication between client 
side communications servers of the same firm (internal 
replication) is handled directly between the two (or more) 
client side communications servers themselves. 

In a preferred embodiment, there are three types of 
content, Base Content, Adhoc Content, and Mixed Content, 25 
that can be replicated throughout the domain. (Also in a 
preferred embodiment, there is a fourth type of content 
known as SystemContent, but this type is not replicated). 
The type of content is determined by how the content is 
organized. Base content is content which is organized by 30 
topic or subject matter. The subject matter must be defined 
within one or more of the domain's Index Objects. The 
origin of the content (i.e. where is was created) is not 
relevant. Base content may have more than one index 
associated with it. Adhoc content, on the other hand, is 35 
content which is organized by its origin and not its subject 
matter. The origin must be one or more of the "producing" 
groups at a given client side communicatioDS server within 
the domain. Mixed Content is a combination of both adhoc 
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which are used to collect and distribute content throughout 
the domain. The type of content is not relevant to the 
replication process since only client side communications 
servers need to understand about its type (in order to process 
it) and the content is encapsulated within a 
DistributedObject, The DistributedObject consists of four 
parts, the origin, the target, the data, and the signature. The 
origin and targets are used by the domain communications 
server to determine who can receive the object, while the 
signature and data portions are used by the client side 
communications server to restore the object in order to 
process. 

In a preferred embodiment, replication is initiated by a 
client side communications server which has predetermined 
to distribute content externally. In a preferred embodiment, 
the client side communications server stores the Distribut- 
edObject locally and notifies the domain communications 
server that a DistributedObject is waiting for delivery at the 
client side communications server site. The client side 
communications server specifies a unique identifier to the 
DistributedObject that the domain communications server 
should use when collecting the object. The client side 
communications server does this through the DistributeOb- 
ject URL 112 of FIG. 8a. 

An example of a client side communications server 
attempting to notify the domain communications server to 
Distribute an Object may look like this: 

https://myDomainSeiver.com:81/DistributeObject?ID=https:// 
ValidCSS. com:84&OID=3043.201e 

1 In response to the DistributeObject Url 112 of FIG. 8a, the 
domain communications server will return the HTTP status 
code 200 signaling the client side communications server 
that its notification was noted. After the notification is sent, 
the domain communications server requests the Distribut- 
edObject from the original client side communications 
server using the unique identity previously specified. This is 
accomplished by requesting the Collectobject URL 114 of 
FIG. 8a, 

An example of a domain communications server collect- 
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and base content. Mixed has both an origin and subject 40 ^ g a Distributed Object from a client side communications 



matter associated with it. 

In a preferred embodiment, mixed content can be of two 
separate types, uncoupleable and decoupleable. Uncou- 
pleable mixed content is content that cannot be broken into 
its base and adhoc parts and must be treated as a whole, 
whereas decoupleable can be broken into its subcomponents 
and treated separately. The type of content is determined by 
the producing client side communications server at the time 
of content creation 



server might look like: 

http5://vaIidCSS.com:84/CollcctObicct?OID=3043.201e 

The response from the client side communications server 
is the requested DistributedObject in stream form. The 
stream is captured by the domain communications server 
and recreated into a DistributedObject at the domain com- 
munications server site. The client side communications 
server will note the time locally that the DistributedObject 

~ . - ■ f^r- 



^ftyLTfTplicaUon of content can be one of two 50 has been retrieved by the domain communications server for 
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possible modes, Broadcast or Selective Distribution, and is 
controlled by the client side communications server based 
on possible destinations permissioned to the producing 
individual at the client side communications server site. 
Broadcasting content has the effect of distributing the (base) 
content to all other client side communications servers 
within the domain in which that originating client side 
communications server has established virtual pipes. Selec- 
tive Distribution will only replicate (adhoc and/or mixed 
content) to the specified client side communications servers 
and not the entire domain. In a preferred embodiment, the 
type of replication specified dictates the type of content 
being replicated. That is, only Base Content can be broad- 
casted and only Adhoc and Mixed Content can be selectively 
distributed. 

Flow of content is controlled by the DistributeObject URL 
112 of FIG. 8a and the CollectObject URL 114 of FIG. 8a 



U<U)U66UIVU1VTV U v; m-- 

auditing purposes. After receiving the DistributedObject the 
domain communications server will determine the source 
and list of possible targets specified. The domain commu- 
nications server will map the targets with those destinations 
with which the originating client side communications 
server has established a virtual pipe. The DistributedObject 
is then stored by the domain communications server locally 
in the DCObjects table 62 as shown in FIG. 6a, and each 
validated destination is stored within a DCobjectdestinalions 
table. The domain communications server will then notify 
each client side communications server destination that a 
DistributedObject is waiting for it. This is done through the 
use of the ReceiveObject URL 212 of FIG. 8Z>, a client side 
server URL. A unique identifier for the specified Distribut- 
edObject is passed in the URL and is used by the receiving 
client side communications server when requesting the 
object. 
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An example of a domain communications server notifying 
a client side communications server that a Distributed 
Object is available might look like: 

https:^lidCSS,com:84/ReceiveObjcct?LOH-1010982029384 

In response to this URL the client side communications 
server will return the HTTP status code 200 signaling the 
domain communications server that its notification was 
noted After the notification is sent, the client side commu- 
nications server requests the DistributedObject from the 
domain communications server using the unique identity 
specified. This is accomplished by requesting the CollectO- 
bject URL 114 of FIG. 8a. 

An example of a client side communications server 
attempting to retrieve a DistributedObject from the domain 
communications server might look like: is 

http://myDoinainServeT.com:81/ColLectObject?ID=https:// 
validCSS.com:84&LOH«101 0982029384 

The response from the domain communications server is 
the requested DistributedObject in stream form. The stream 
is captured by the client side communications server and 
recreated into a DistributedObject at the client side commu- 
nications server site. The domain communications server 
will note the time locally that the DistributedObject has been 
retrieved by the client side communications server for 25 
auditing purposes. After receiving the DistributedObject the 
client side communications server will determine if further 
processing is needed and do so accordingly 
4. Dynamic client registry changes 

In a preferred embodiment, dynamic client registry 06, as 30 
shown in FIG. 5, is used to determine what resources are 
available within a given domain at a given point in time. 
Dynamic client registry 06 consists of the following four 
objects: content producers, content consumers, index 
objects, and channels. Dynamic client registry 06 is dynamic 35 
in nature, and changes to it are controlled by the domain 
communications server and can occur at any point in time. 
The domain communications server is responsible for noti- 
fying all client side communications servers of any changes. 
This is done through Refresh URL 118 of FIG. Ha. 40 

In a preferred embodiment, changes to dynamic client 
registry 06 occur as a result of four different events. The first 
is the registering of a new client side communications server 
within the domain. This will cause the domain communica- 
tions server to notify all other "interested" client side 45 
communications servers of this new client side communi- 
cations server. Notification consists of the listing of Con- 
tentProducers and ContentConsumers that the registering 
client side communications server contains that are now 
available to all other existing client side communications 50 
servers. It is the domain communications server's respon- 
sibility to determine which client side communications 
servers see which producers and consumers (based on the 
established virtual pipes). In a preferred embodiment, a 
client side communications server can selectively choose to 55 
notify only a subset of those the domain communications 
server says are available. 

The second event causing a change in dynamic client 
registry 06 is the opposite of the first, namely the Deregis- 
tration of a client side communications server. In either 60 
event the domain communications server will notify all 
relevant client side communications servers of changes to 
both ContentProducers and ContentConsumers objects. 

An example of a domain communications server notifying 
a client side communications server of a change to dynamic 65 
client registry 06, (specifically ContentProducers) might 
look like: 



https:/A^UdCSS.com:84/Rcfrcsli?URL=/Froducers 

An example of a domain communications server notifying 
a client side communications server of a change to dynamic 
client registry 06 (specifically ContentConsumers) might 
look like: 

https^alidCSS.com:84/Refire6b?URl^/Consiiiners 

The third type of change to dynamic client registry 06 is 
a change in the IndexObjects used by the domain. This may 
only occur through the Status events (listed below) handled 
by the domain communications server. All valid client side 
communications servers are notified of this type of change 
to dynamic client registry 06. 

An example of a domain communications server notifying 
a client side communications server of changes to dynamic 
client registry 06, (specifically IndexObjects) might look 
like: 

https:/A'alidCSS.com:84/Re£resh7URl^Ind&xes 

The last type of change is a change in the Channels used 
by the domain. This may only occur through the Status 
events (explained below) handled by the domain commu- 
nications server. All registered client side communications 
servers are notified of this type of change. 

An example of a domain communications server notifying 
a client side communications server of changes to dynamic 
client registry 06 (specifically Channels) might look like: 

https://validCSS.com:84/Refresh?URL=/Channel 

In response to this URL the client side communications 
server will return the HTTP status code 200 signaling the 
domain communications server that its notification was 
received by the client side communications server. After the 
notification is sent, the client side communications server 
will request the URL (with the required parameters) speci- 
fied from the domain communications server. 
5. Domain Shutdown 

This event occurs, when the domain communications 
server must notify all valid client side communications 
servers that it is no longer available. This notification is 
handled via DomainSbutdown URL 130 of FIG. 8a. 

An example of a domain communications server notifying 
a client side communications server of the domain shutdown 
might look like: 

https://validCSS.com:84/DomainShutdown 

In a preferred embodiment, notification is sent to the 
client side communications server to allow the client side 
communications server to begin queuing any content that 
must be replicated externally until the domain communica- 
tions server notifies the client side communications server 
that it has once again become available. The client side 
communications server may use an alternative domain com- 
munications server (if one is specified when starting the 
client side communications server) until the original domain 
communications server returns to avoid having to queue any 
content. Upon return of the domain communications server 
to the domain, the client side communications server will 
notify the domain communications server of any content that 
is currently queued by initiating content replication (event 3 
above). Notification of the domain communications server's 
return is done by the domain communications server 
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requesting each client side communications server to 
re-register (event 1). 

6- Status , M . . . 

In a preferred embodiment, events are handled by the 
domain communications sever in response to queries about s 
the current Status of the domain and changes to those 
portions of dynamic client registry 06 which are oertraUy 
hosted by the domain communications server (namely Chan- 
nels and Index Objects). These events are not available to 
any client side communications server but only to the 1Q 
domain communications server administrators. Status 
events will display the current status of all client side 
communications servers within the domain. The status of a 
cUent side communications server includes the currently 
established virtual pipes to other client side communications 
servers, the content producers (both internal and external) of 
a client side communications server, and the content con- 
sumers of a client side communications server (as well as 
what the consumers are consuming). The domain commu- 
nications server may be told to reload the domain's mdexes 
or channels through these events. 

As mentioned, in a preferred embodiment, the system also 
uses a DistributedObject Object. The DistributedObject is 
used to replicate data from one client side communications 
server to another within a given domain. The DistributedOb- 
ject has four components that make it up: the origin, the 2 5 
target, the signature, and the data (the content) being repli- 
cated. The origin and target fields are set by the client side 
communications server creating the data and evaluated by 
the domain communications server when determining the 
possible destinations to which the data may replicate. The 30 
signature is used by the receiving client side communica- 
tions server to reconstruct from the data its original type and 
to understand how to process it. A DistributedObject is 
persistent, The origins and destinations are in the form of 
IdObjects. Multiple destinations and origins may be speci- 35 

In a preferred embodiment, the IdObject is used to deter- 
mine the destination or source of the domain's content. It is 
made up of the firm, workgroup, and user identifications and 
is used by both the domain communications server and 40 
client side communications servers to determine the origin 
or targets for contents. This object allows for wild card 
abbreviations to denote all possible matches and can deter- 
mine if a given IdObject is "equal to" another IdObject. 
Valid Idobjects are in the following form and sample wild 
card abbreviations for them are shown as: 



IdObject 



Equivalence 



• *+ all users in all groups within all firms 

FIRM.*.* all users in all groups at a specific flim. 

FIRM.GROUP.* all users in a specific group of a specific firm 

FIRM.GROUP.USER specific user in a specific gr oup of a specific firm 

As will be apparent to those skilled in the art, when 
multiple domain communications servers are used a domain 
field will be included in front of the firm field. 

In a preferred embodiment of the present invention, 
readership analysis and similar statistical information can be 
kept, if desired, about the use, copying, accessing or types of 
information referred to by users. As will be apparent to those 
skilled in the art, analysis programs to track other types of 
use, traffic flow, response times, and so on could also be 
implemented without deviating from the spirit of the present 
invention. 

In a preferred embodiment of the present invention, the 
system can also provide a distribution summary that, for 



example, allows a user to review at the end of a day, all the 
information sent out by the user at the end of a that day, or 
another time period. 

Also in a preferred embodiment, the system provides 
search features to allow a user to search for information 
based on the information's type or source or both, as well as 
such other factors as creation date, publication within a time 
frame and so on. As will be apparent to those skilled in the 
art, a number of differing search functions can be imple- 
mented without deviating from the spirit of the present 
invention. 

In a preferred embodiment, a producer object (which lists 
the firm name, the group name, etc.,) also lists the producer 
individuals with whom a receiving consumer can commu- 
nicate on a one to on basis. Similarly, the consumer object, 
amongst other items, includes a list indicating producing 
individuals to whom it is willing to talk on a one to one 
basis. This one-to-one communications facility of the 
present invention permits highly confidential communica- 
tions to occur on a one-to-one "for your eyes only" basis, if 
desired. As will be apparent to those skilled in the art, 
various combinations and variations of this one-to-one rela- 
tionship management are possible. 

Similarly, in a preferred embodiment a comment can be 
tagged with more than one index value. 

While a preferred embodiment of the present invention is 
implemented as a program written in the C++ programming 
language and operates on personal computers or worksta- 
tions using the NT or Unix operating systems, as will be 
apparent to those skilled in the art, other programming 
languages and operating systems could be used. 
Additionally, although the preferred embodiment uses a 
software program implementation, it will be apparent that 
some or all of the logic of the present invention could also 
be embodied in firmware or hardware circuitry. 

Those skilled in the art will appreciate that the embodi- 
ments described above are illustrative only and that other 
systems in the spirit of the teachings herein fall within the 
scope of the invention. 
What is claimed is: 

1. An apparatus for managing event-driven communica- 
tions between different client entities on different networks 
comprising: 

a first computer having electronic storage media for 
storing a dynamic client registry thereon and for storing 
resource locators containing function names thereon, 
the first computer further comprising a web server 
program which, when executed by the first computer, 
causes the first computer to respond to the resource 
locators by calling the function name indicated therein 
into the first computer, the first computer further com- 
prising a database management program for organizing 
the dynamic client registry; 
a domain communications server program which, when 
loaded by the web server program responding to the 
appropriate resource locator therefor, is executed by the 
first computer, and is further responsive to resource 
locators directed to the domain communications server 
program for directing the database management pro- 
gram in organizing the dynamic client registry to map 
and authorize an interclient and intra-client communi- 
cations infrastructure and the contents thereof; 
a second computer in communications relationship with 
the first computer, the second computer having elec- 
tronic storage media for storing a dynamic group 
registry thereon and for storing resource locators con- 
taining function names thereon, the second computer 
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father comprising a web server program which, when 
executed by the second computer, causes the second 
computer to respond to resource locators by calling the 
function name indicated therein into the second 
computer, the second computer further comprising a 5 
database management program for organizing the 
dynamic group registry; 
a client side communications server program which, when 
loaded by the web server program responding to the 
appropriate resource locator therefor, is executed by the 10 
second computer, and is further responsive to resource 
locators directed to the client side communications 
server program for directing the database management 
program in organizing the dynamic group registry to 
map and authorize an inter-group and intra-group com- 15 
munications infrastructure and the contents thereof; 
a domain communications resource locator list stored in 
the first and second computers that causes predeter- 
mined functions to be selected for execution in the 
domain communications server in the first computer; 20 
a client side communications resource locator list stored 
in the first and second computers that causes predeter- 
mined functions to be selected for execution in the 
client side communications server in the second com- 
puter so that communications between the first com- 25 
puter and the second computer cause the selected 
functions to be executed dynamically in order to route 
contents as communication events occur according to 
the maps in the dynamic client registries and dynamic 
group registries so that clients can be registered and 30 
unregistered dynamically at a local client level, content 
can be created and deleted dynamically at a local client 
level, and content can be replicated dynamically at a 
local client level amongst internal client groups and 
automatically replicated externally to authorized exter- 35 
nal clients and groups, thereby enabling interactive 
communications amongst groups and clients over 
physically different networks. 

2. The apparatus of claim 1, wherein the domain com- 
munications resource locator list includes a register domain 40 
communications resource locator that causes the domain 
communications server program to direct the database man- 
agement program to dynamically register a client side com- 
munications server program in the dynamic client registry. 

3. The apparatus of claim 1, wherein the client side 45 
communications resource locator list includes publications 
control resource locators that enable the client side commu- 
nications server program to direct the database management 
program executing in the second computer to organize 
content information created and received by users in com- 50 
munications relationship with the second computer into the 
dynamic group registry thereof. 

4. The apparatus of claim 3 wherein the domain commu- 
nications server resource locator list includes collection 
resource locators that enable the domain communications 55 
server program to collect map and content information 
referenced in the dynamic group registry of the second 
computer for storing in the dynamic client registry of the 
first computer. 

5. The apparatus of claim 4, wherein the domain com- 60 
munications server resource locator list and the client side 
communications server resource list include indexing 
resource locators that enable the client side communications 
server program to direct the database management program 
to store the content information collected from a client user 65 
in the dynamic group registry according to specified index- 
ing criteria. 
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6. The apparatus of claim 5, wherein the domain com- 
munications server resource locator list includes consumers 
resource locators that enable the domain communications 
server program to direct the database management program 
to organize the map information stored in the dynamic client 
registry according to lists of authorized receivers of the 
information, 

7. The apparatus of claim 6, further comprising: 
a third computer in communications relationship with the 

first computer and having electronic storage media for 
storing a second dynamic group registry thereon and 
for storing resource locators containing function names 
thereon, the third computer further comprising a web 
server program which, when executed by the third 
computer, causes the third computer to respond to 
resource locators by calling the function name indi- 
cated therein into the third computer, the third com- 
puter further comprising a database management pro- 
gram for organizing the second dynamic group registry; 
a client side communications server program which, when 
loaded by the web server program responding to the 
appropriate resource locator therefore, is executed by 
the third computer, and is further responsive to resource 
locators directed to the client side communications 
server program and directs the database management 
program in organizing the second dynamic group reg- 
istry; and 

a domain communications server resource locator list 
including notification resource locators that enable the 
domain communications server program to notify the 
third computer whether content information stored and 
indexed in the dynamic client registry of the first 
computer is available and authorized to be collected by 
the third computer. 

8. The apparatus of claim 7, wherein the client side 
communications resource locator list includes collection 
resource locators that enable the client side communications 
server program to collect content information stored on the 
dynamic client registry of the first computer in response to 
a notification from the first computer that content informa- 
tion the client side communications server program is autho- 
rized to receive is available. 

9. The apparatus of claim 1, wherein the client side 
communications server program further includes a queuing 
mechanism for storing messages containing domain com- 
munications resource locators for later transmission, when 
the client side communications server program dynamically 
detects that the domain communications server is not able to 
receive messages. 

10. The apparatus of claim 1, wherein the domain com- 
munications server program further includes a queuing 
mechanism for storing messages containing client side com- 
munications resource locators for later transmission, when 
the domain communications server program dynamically 
detects that the client side communications server is not able 
to receive messages. 

11. The apparatus of claim 7, wherein map information 
about producers, Consumers and authorized receivers stored 
in the dynamic client registry is used by the domain com- 
munications server to create virtual pipes for directing 
content information stored in the dynamic client registry to 
different entities on different networks. 

12. A computer implemented method for managing event- 
driven communications between different client entities on 
different networks comprising the steps of: 

storing a dynamic client registry and resource locators 
containing function names on a first computer having 
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electronic storage media, the first computer further 
executing a web server program which causes the first 
computer to respond to the resource locators by calling 
the function name indicated therein into the first 
computer, the first computer directing a database man- 
agement program for organizing the dynamic client 
registry; 

executing a domain communications server program 
loaded into the first computer by the web server pro- 
gram responding to the appropriate resource locator 
therefor, for responding to resource locators directed to 
the domain communications server program for direct- 
ing the database management program in organizing 
the dynamic client registry to map and authorize an 
inter-client and intra-client communications infrastruc- 
ture and the contents thereof; 
storing a dynamic group registry and resource locators 
containing function names on a second computer in 
communications relationship with the first computer, 
the second computer having electronic storage media 
and executing a web server program which causes he 
second computer to respond to resource locators by 
calling the function name indicated herein into the 
second computer, the second computer also directing a ^ 
database management program for organizing the 
dynamic group registry; 
executing a client side communications server program 
loaded by the web server program responding to the 
appropriate resource locator therefor, for responding to 3Q 
resource locators directed to the client side communi- 
cations server program for directing the database man- 
agement program in organizing the dynamic group 
registry to map and authorize an inter-group and intra- 
group communications infrastructure and the contents 35 
thereof; 

storing a domain communications resource locator list in 
the first and second computers to allow predetermined 
functions to be selected for execution in the domain 
communications server in the first computer, 4C 

storing a client side communications resource locator list 
stored in the first and second computers to allow 
predetermined functions to be selected for execution in 
the client side communications server in the second 
computer so that communications between the first At 
computer and the second computer cause the selected 
functions to be executed dynamically in order to route 
contents as communications events occur according to 
the maps in the dynamic client registries and dynamic 
group registries so that clients can be registered and 
unregistered dynamically at a local client level, content 
can be created and deleted dynamically at a local client 
level, and content can be replicated dynamically at a 
local client level amongst internal client groups and 
automatically replicated externally to authorized exter- 
nal clients and groups, thereby enabling interactive 
communications amongst groups and clients over 
physically different networks. 

13. The method of claim 12, wherein the step of storing 
a domain communications resource locator list further com- 
prises the step of storing a register domain communications 
resource locator therein that causes the domain communi- 
cations server program to direct the database management 
program to dynamically register a client side communica- 
tions server program in the dynamic client registry. 

14. The method of claim 12, wherein the step of storing 
the client side communications resource locator list further 



comprises the step of storing publications control resource 
locators therein that enable the client side communications 
server program to direct the database management program 
executing in the second computer to organize content infor- 
mation created and received by users in communications 
relationship with the second computer into the dynamic 
group registry thereof. 

15. The method of claim 12 wherein the step of storing a 
domain communications server resource locator list further 
comprises the step of storing collection resource locators 
therein that enable the domain communications server pro- 
gram to collect map and content information referenced in 
the dynamic group registry of the second computer for 
storing in the dynamic client registry of the first computer. 

16. The method of claim 15, wherein the steps of storing 
the domain communications server resource locator list and 
the client side communications server resource locator list 
further comprises the step of storing indexing resource 
locators in each that enable the client side communications 
server program to direct the database management program 
to store the content information collected from a client user 
in the dynamic group registry according to specified index- 
ing criteria. 

17. The method of claim 16, wherein the step of storing 
the domain communications server resource locator list 
further comprises the step of storing consumers resource 
locators therein that enable the domain communications 
server program to direct the database management program 
to organize the map information stored in the dynamic client 
registry according to lists of authorized receivers of the 
content information. 

18. The method of claim 17, further comprising the step 

of: 

communicating with the first computer from a third 
computer having electronic storage media for storing a 
second dynamic group registry thereon and for storing 
resource locators containing function names thereon, 
the third computer further comprising a web server 
program which, when executed by the third computer, 
causes the third computer to respond to resource loca- 
tors by calling the function name indicated therein into 
the third computer, the third computer further compris- 
ing a database management program for organizing the 
second dynamic group registry; 
executing a client side communications server program on 
the third computer in response to the appropriate 
resource locator therefor, for responding to resource 
locators directed to the client side communications 
server program on the third computer and directing the 
database management program in organizing the sec- 
ond dynamic group registry; and 
storing a domain communications server resource locator 
list on the third computer, for including notification 
resource locators that enable the domain communica- 
tions server program to notify the third computer 
whether content information stored and indexed in the 
dynamic client registry of the first computer is available 
and authorized to be collected by the third computer. 
19. The method of claim 18, wherein the step of storing 
> the client side communications resource locator list further 
comprises the step of storing collection resource locators 
therein that enable the client side communications server 
program to collect content information stored on the 
dynamic client registry of the first computer in response to 
a notification from the first computer that content informa- 
tion the client side communications server program is autho- 
rized to receive is available. 
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20. The method of claim 12, wherein the step of executing 
the client side communications server program further the 
step of queuing and storing messages containing domain 
communications resource locators for later transmission, 
when the client side communications server program 5 
dynamically detects that the domain communications server 

is not able to receive messages. 

21. The method of claim 12, wherein the step of executing 
the domain communications server program further com- 
prises the step of queuing and storing messages containing 10 
client side communications resource locators for later trans- 
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mission when the domain communications server program 
dynamically detects that the client side communications 
server is not able to receive messages. 

22. The method of claim 18, wherein the step of storing 
map information about producers, consumers and authorized 
receivers in the dynamic client registry further comprises the 
step of the domain communications server's creating virtual 
pipes for directing content information stored in the dynamic 
client registry to different entities on different networks. 

* * * * * 
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